Re: [jira] [Updated] (IGNITE-4052) Add ability to set up users for MESOS

2017-04-13 Thread Вадим Опольский
Hello guys!

Nikolai, I improved method getRole and getUser,

Review please again:

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

but what do mean about override ?

Something like this:

public class IgniteFrameworkUnderTest extends IgniteFramework{

...
@Override
public String getUser(){
...
}

@Override
public String getRole(){
...
}

}

Vadim Opolski


2017-04-13 16:39 GMT+03:00 Nikolai Tikhonov (JIRA) :

>
>  [ https://issues.apache.org/jira/browse/IGNITE-4052?page=
> com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Nikolai Tikhonov updated IGNITE-4052:
> -
>
> Vadim,
>
> I've left comment in the ticket.
>
> On Wed, Apr 12, 2017 at 3:00 PM, Вадим Опольский 
>
>
>
> > Add ability to set up users for MESOS
> > -
> >
> > Key: IGNITE-4052
> > URL: https://issues.apache.org/jira/browse/IGNITE-4052
> > Project: Ignite
> >  Issue Type: Improvement
> >  Components: general
> >Affects Versions: 1.7
> >Reporter: Nikolay Tikhonov
> >Assignee: Vadim Opolski
> >Priority: Trivial
> >
> > In current implementation Ignite Mesos Framework connects to MESOS
> cluster via current user. Need to add ability to configure this parameters
> via system env properties. Also need to add properties for mesos role.
> > See org/apache/ignite/mesos/IgniteFramework.java:537
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.15#6346)
>


Re: Apache Ignite 2.0 Documentation

2017-04-13 Thread Dmitriy Setrakyan
Denis, thanks for tracking the documentation changes! This is the part that
usually gets missed by the community.

On Thu, Apr 13, 2017 at 12:46 PM, Denis Magda  wrote:

> Folks,
>
> I’ve prepared a list of changes that have to be documented before the
> public release of 2.0:
> https://issues.apache.org/jira/browse/IGNITE-4960
>
> That’s an impressive release and there are some many things to document.
> Actually, I’ll try to document the biggest part contacting contributors in
> person but still need a help from some of you:
>
> * Nikita, Oleg (Machine Learning): https://issues.apache.org/
> jira/browse/IGNITE-4964
> * Vovan or Alex P. (DDL indexing statements): https://issues.apache.org/
> jira/browse/IGNITE-4967
> * Vovan (custom thread pools): https://issues.apache.org/
> jira/browse/IGNITE-4969
> * Vovan or Taras (next gen async API): https://issues.apache.org/
> jira/browse/IGNITE-4972
> * Val (Hibernate improvements): https://issues.apache.org/
> jira/browse/IGNITE-4972
> * Pavel (.NET plugin system): https://issues.apache.org/
> jira/browse/IGNITE-4973
> * Pavel (.NET dynamically registered classes): https://issues.apache.org/
> jira/browse/IGNITE-4974
> * Igor Sapego (C++ CQ remote filters): https://issues.apache.org/
> jira/browse/IGNITE-4976
>
> Let’s pull together and accomplish this part of the release together.
>
> —
> Denis
>
>


Re: TouchedExpiryPolicy works incorrect in some cases IGNITE-4401

2017-04-13 Thread Denis Magda
I could reproduce the issue and this should be what Denis K. meant by saying 
“expiration policy works incorrectly”. 

If you remove the expiration policy from the caches' configuration then the 
issue disappears. In general, SQL engine processes an expiration event properly 
because the SQL queries return an empty result set as expected but something 
doesn’t work well with key-value operations.

*Denis K*, *Vlad P.*, as creators of the ticket please confirm that this is the 
case.

Please keep debugging this and switch to the latest Ignite version.

—
Denis


> On Apr 13, 2017, at 4:22 AM, ALEKSEY KUZNETSOV  
> wrote:
> 
> any feedback?
> 
> чт, 13 апр. 2017 г. в 11:51, ALEKSEY KUZNETSOV :
> 
>> You should run ExpiryPolicyTest. The output should contain strings like
>> contains? new AffinityKey("1", "1"): and contains?2 new AffinityKey("1", "
>> 1"): and empty cursor? =
>> If you look at them you will see, that cache contains affinity key new
>> AffinityKey("1", "1") whereas cursor is empty(on second iteration). From
>> this output you can conclude SQL query returns icorrect data(empty value)
>> 
>> 
>> чт, 13 апр. 2017 г. в 3:42, Denis Magda :
>> 
>>> Bluntly speaking I have no idea where to look and what to expect. This is
>>> output of the test execution of my machine:
>>> 
>>> SQL res: [[1], [d]]
>>> 2
>>> Op consume: 303
>>> Value: org.ignite.test.EDU@22db8f4
>>> SQL res: []
>>> 0
>>> Op consume: 9
>>> Value: org.ignite.test.EDU@29caf222
>>> SQL res: []
>>> 0
>>> Op consume: 15
>>> Value: org.ignite.test.EDU@7cd1ac19
>>> SQL res: []
>>> 0
>>> Op consume: 5
>>> 
>>> Please be more specific, there are too many files in the code.
>>> 
>>> —
>>> Denis
>>> 
 On Apr 12, 2017, at 4:50 AM, ALEKSEY KUZNETSOV <
>>> alkuznetsov...@gmail.com> wrote:
 
 So what do u think about the issue ?
 
 ср, 12 апр. 2017 г. в 10:42, ALEKSEY KUZNETSOV <
>>> alkuznetsov...@gmail.com>:
 
> I have already attached simlified version. Shall i simplify it more ?
> 
> вт, 11 апр. 2017 г. в 19:28, Denis Magda :
> 
> Can you attach the simplified version? Just want to avoid any side
>>> effects.
> 
> —
> Denis
> 
>> On Apr 11, 2017, at 9:14 AM, ALEKSEY KUZNETSOV <
>>> alkuznetsov...@gmail.com>
> wrote:
>> 
>> I took it from https://issues.apache.org/jira/browse/IGNITE-4401 <
> https://issues.apache.org/jira/browse/IGNITE-4401> and simplified .
>>> See
> in attached
>> 
>> 
>> вт, 11 апр. 2017 г. в 19:03, Denis Magda >:
>> Hello,
>> 
>> Do you have sample code?
>> 
>> —
>> Denis
>>> On Apr 11, 2017, at 2:45 AM, ALEKSEY KUZNETSOV <
> alkuznetsov...@gmail.com > wrote:
>>> 
>>> Hi, igniters!
>>> While doing https://issues.apache.org/jira/browse/IGNITE-4401 <
> https://issues.apache.org/jira/browse/IGNITE-4401> ticket i came
>>> across the fact that cache querying returns null , while cache still
> has
>>> got entry.
>>> Cache query : SELECT nameProp FROM EDUProp WHERE EDUId = 1
>>> Cache get operation : ignite().cache("eduPropCache").get(new
> AffinityKey("1",
>>> "1")) non-null
>>> I cannot even imagine what could be wrong with it.
>>> 
>>> 
>>> 
>>> --
>>> 
>>> *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: question: How data are stored in IgniteCache?

2017-04-13 Thread Denis Magda
A serialized object is always wrapped by BinaryObjectImpl when it’s stored in 
memory in a specific cache partition or you access it from your application in 
a form of BinaryObject. However, when you transfer the object over the wire or 
put it into a persistent store (withKeepBinary property enabled) then only the 
byte array is used.

—
Denis

> On Apr 13, 2017, at 12:21 AM, Vyacheslav Daradur  wrote:
> 
> Denis, thank you for answers.
> 
> I meant another.
> 
> For example:
> Cache queries use a BinaryObjectImpl and a withKeepBinary-mode use it, so
> looks like all actions on serialized object are make via a BinaryObjectImpl.
> 
> Does a serialized object always is stored as BinaryObjectImpl or it will be
> wrapped on demand?
> 
> 2017-04-12 22:34 GMT+03:00 Denis Magda :
> 
>> A Java wrapper around an actual binary byte array with some additional
>> fields and methods to work with the serialized data.
>> 
>> —
>> Denis
>> 
>>> On Apr 12, 2017, at 8:33 AM, Vyacheslav Daradur 
>> wrote:
>>> 
>>> In what cases BinaryObjecImpl is used?
>>> 
>>> 2017-04-12 18:08 GMT+03:00 Denis Magda :
>>> 
 Hi,
 
 A cache entry is always stored in a binary format (byte array) in a
>> cache.
 Even when you transfer an entry from one node to another, as a result of
 cache.put(…), operation the entry will be serialized into the binary
>> format
 and transferred over the wire.
 
 —
 Denis
 
> On Apr 12, 2017, at 1:11 AM, Vyacheslav Daradur 
 wrote:
> 
> Hello Igniters!
> 
> I have one conceptual question:
> 
> When we put an object in IgniteCache, how it is stored?
> 
> As I understand, after marshalling we have an array of bytes,
> 1) in a local node it is wrapped in BinaryObjectImpl and stored in
>> memory
> 2) it is sent to remote node as byte array where it will be wrapped in
> BinaryObjectImpl and be stored in memory
> 
> --
> Best Regards, Vyacheslav
 
 
>>> 
>>> 
>>> --
>>> Best Regards, Vyacheslav
>> 
>> 
> 
> 
> -- 
> Best Regards, Vyacheslav



Re: IGNITE-2741 - spring session design

2017-04-13 Thread Valentin Kulichenko
Hi Rishi,

Good news :) Thanks for letting me know.

-Val

On Thu, Apr 13, 2017 at 9:29 PM, Rishi Yagnik  wrote:

> Hello Val,
>
> I debug further and found out that issue exist with SPA ( Angular APP ) and
> it needs a fix on their end so don't worry about it.
>
> Next week, I will deploy it in a cluster and let you know if that fixes
> session replication issue on cluster.
>
> Thanks,
> Rishi
>
>
> On Thu, Apr 13, 2017 at 7:55 AM, Rishi Yagnik 
> wrote:
>
> > Val,
> >
> > Yes I would provide you the exact steps today and I will also test it in
> > cluster environment.
> >
> > The local environment is working as expected with the fix.
> >
> > Take Care,
> > Rishi
> >
> > > On Apr 13, 2017, at 2:18 AM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> > >
> > > Rishi,
> > >
> > > Can you tell exact steps to reproduce? It's working for me in my
> > > environment.
> > >
> > > Do I understand correctly that apart from the token issue, it works
> fine
> > > with new version?
> > >
> > > -Val
> > >
> > > On Wed, Apr 12, 2017 at 10:00 PM, Rishi Yagnik 
> > > wrote:
> > >
> > >> Val,
> > >>
> > >> I build it from master s and was able to integrate with our app, but
> as
> > I
> > >> mentioned to you previously, I see the XSRF-Token errors in debug log,
> > >>
> > >> [DEBUG] [XNIO-2 task-4] org.springframework.security.
> > web.FilterChainProxy
> > >> -
> > >> /app/xxx/yyy/zz/A at position 3 of 13 in additional filter chain;
> firing
> > >> Filter: 'HeaderWriterFilter'
> > >> [DEBUG] [XNIO-2 task-4] org.springframework.security.
> > web.FilterChainProxy
> > >> -
> > >> /app/xxx/yyy/zz/A at position 4 of 13 in additional filter chain;
> firing
> > >> Filter: 'CsrfFilter'
> > >>
> > >> [DEBUG] [XNIO-2 task-4] org.springframework.security.
> web.csrf.CsrfFilter
> > -
> > >> Invalid CSRF token found for http://localhost:9002/app/xxx/yyy/zz/A
> > >>
> > >> And, then after, CSRF filter does not like the session, redirects to
> > /403
> > >> error.
> > >>
> > >> Just wondering why the XSRF Token is not being saved in the session  ?
> > >>
> > >> More debugging is require for sure..
> > >>
> > >> of course there is a work around to the problem, I can just use Cookie
> > >> based Token repository to avoid this issue.
> > >>
> > >> .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse())
> > >>
> > >>
> > >> will let you know my findings..
> > >>
> > >> As always, thanks for all your help.
> > >>
> > >> Thanks,
> > >> Rishi
> > >>
> > >>
> > >> On Tue, Apr 11, 2017 at 4:18 PM, Rishi Yagnik 
> > >> wrote:
> > >>
> > >>> Hi Val,
> > >>>
> > >>> I will build it from master s and let you know by tomorrow.
> > >>>
> > >>> Thanks,
> > >>>
> > >>>
> > >>> On Tue, Apr 11, 2017 at 3:53 PM, Valentin Kulichenko <
> > >>> valentin.kuliche...@gmail.com> wrote:
> > >>>
> >  Hi Rishi,
> > 
> >  What was the issue with the HttpSessionCsrfTokenRepository? I
> didn't
> > >> have
> >  any problems after I added code you provided.
> > 
> >  The fix for [1] is already in master. Can you try building from
> there
> > >> and
> >  check if everything works fine for you?
> > 
> >  [1] https://issues.apache.org/jira/browse/IGNITE-4948
> > 
> >  -Val
> > 
> >  On Sat, Mar 18, 2017 at 5:15 PM, Denis Magda 
> > >> wrote:
> > 
> > > Somewhere in April. This will be clarified on the dev list soon.
> > >
> > > On Saturday, March 18, 2017, Rishi Yagnik 
> >  wrote:
> > >
> > >> Thanks, Val.
> > >>
> > >> When are we going to release Ignite 2.0 ? June ??
> > >>
> > >> Thanks,
> > >>
> > >> On Sat, Mar 18, 2017 at 6:02 AM, Valentin Kulichenko <
> > >> valentin.kuliche...@gmail.com > wrote:
> > >>
> > >>> Denis,
> > >>>
> > >>> Yes, this should be possible. I will try to finalize the fix
> asap.
> > >>>
> > >>> -Val
> > >>>
> > >>> On Fri, Mar 17, 2017 at 7:46 PM, Denis Magda  > >> > wrote:
> > >>>
> >  Val,
> > 
> >  Will it be possible to incorporate the fix into the nearest 2.0
> > >> release?
> > 
> >  —
> >  Denis
> > 
> > > On Mar 17, 2017, at 11:43 AM, Rishi Yagnik <
> >  rishiyag...@gmail.com
> > >> >
> >  wrote:
> > >
> > > Hi Val,
> > >
> > > Hope you are well, any update on web session clustering.
> > >
> > > Thanks,
> > > Rishi
> > >
> > > On Sat, Mar 11, 2017 at 12:29 PM, Rishi Yagnik <
> > >> rishiyag...@gmail.com >
> > > wrote:
> > >
> > >> Hi Val,
> > >>
> > >> Thanks looking forward for the fix..
> > >>
> > >> Take Care,
> > >> Rishi
> > 

Apache Ignite 2.0 Documentation

2017-04-13 Thread Denis Magda
Folks,

I’ve prepared a list of changes that have to be documented before the public 
release of 2.0:
https://issues.apache.org/jira/browse/IGNITE-4960

That’s an impressive release and there are some many things to document. 
Actually, I’ll try to document the biggest part contacting contributors in 
person but still need a help from some of you:

* Nikita, Oleg (Machine Learning): 
https://issues.apache.org/jira/browse/IGNITE-4964
* Vovan or Alex P. (DDL indexing statements): 
https://issues.apache.org/jira/browse/IGNITE-4967
* Vovan (custom thread pools): https://issues.apache.org/jira/browse/IGNITE-4969
* Vovan or Taras (next gen async API): 
https://issues.apache.org/jira/browse/IGNITE-4972
* Val (Hibernate improvements): 
https://issues.apache.org/jira/browse/IGNITE-4972
* Pavel (.NET plugin system): https://issues.apache.org/jira/browse/IGNITE-4973
* Pavel (.NET dynamically registered classes): 
https://issues.apache.org/jira/browse/IGNITE-4974
* Igor Sapego (C++ CQ remote filters): 
https://issues.apache.org/jira/browse/IGNITE-4976

Let’s pull together and accomplish this part of the release together. 

—
Denis



[jira] [Created] (IGNITE-4979) Document SQL queries execution started on replicated cache

2017-04-13 Thread Denis Magda (JIRA)
Denis Magda created IGNITE-4979:
---

 Summary: Document SQL queries execution started on replicated cache
 Key: IGNITE-4979
 URL: https://issues.apache.org/jira/browse/IGNITE-4979
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Denis Magda


Refer to IGNITE-4955 for more details.



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


[jira] [Created] (IGNITE-4978) Prepare Apache Ignite 2.0 Migration Guide

2017-04-13 Thread Denis Magda (JIRA)
Denis Magda created IGNITE-4978:
---

 Summary: Prepare Apache Ignite 2.0 Migration Guide
 Key: IGNITE-4978
 URL: https://issues.apache.org/jira/browse/IGNITE-4978
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Denis Magda


There were many big and small changes introduced in Apache Ignite 2.0 that 
break backward compatibility with version 1.x and has to put into the migration 
guide.

Sources for migration guide:
* An umbrella ticket with most significant changes (IGNITE-4960)
* An umbrella ticket with minor tasks (IGNITE-4547)
* Migration guide on Ignite wiki 
(https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide)

Update readme.io documentation if needed.



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


Re: IGNITE-2741 - spring session design

2017-04-13 Thread Rishi Yagnik
Hello Val,

I debug further and found out that issue exist with SPA ( Angular APP ) and
it needs a fix on their end so don't worry about it.

Next week, I will deploy it in a cluster and let you know if that fixes
session replication issue on cluster.

Thanks,
Rishi


On Thu, Apr 13, 2017 at 7:55 AM, Rishi Yagnik  wrote:

> Val,
>
> Yes I would provide you the exact steps today and I will also test it in
> cluster environment.
>
> The local environment is working as expected with the fix.
>
> Take Care,
> Rishi
>
> > On Apr 13, 2017, at 2:18 AM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
> >
> > Rishi,
> >
> > Can you tell exact steps to reproduce? It's working for me in my
> > environment.
> >
> > Do I understand correctly that apart from the token issue, it works fine
> > with new version?
> >
> > -Val
> >
> > On Wed, Apr 12, 2017 at 10:00 PM, Rishi Yagnik 
> > wrote:
> >
> >> Val,
> >>
> >> I build it from master s and was able to integrate with our app, but as
> I
> >> mentioned to you previously, I see the XSRF-Token errors in debug log,
> >>
> >> [DEBUG] [XNIO-2 task-4] org.springframework.security.
> web.FilterChainProxy
> >> -
> >> /app/xxx/yyy/zz/A at position 3 of 13 in additional filter chain; firing
> >> Filter: 'HeaderWriterFilter'
> >> [DEBUG] [XNIO-2 task-4] org.springframework.security.
> web.FilterChainProxy
> >> -
> >> /app/xxx/yyy/zz/A at position 4 of 13 in additional filter chain; firing
> >> Filter: 'CsrfFilter'
> >>
> >> [DEBUG] [XNIO-2 task-4] org.springframework.security.web.csrf.CsrfFilter
> -
> >> Invalid CSRF token found for http://localhost:9002/app/xxx/yyy/zz/A
> >>
> >> And, then after, CSRF filter does not like the session, redirects to
> /403
> >> error.
> >>
> >> Just wondering why the XSRF Token is not being saved in the session  ?
> >>
> >> More debugging is require for sure..
> >>
> >> of course there is a work around to the problem, I can just use Cookie
> >> based Token repository to avoid this issue.
> >>
> >> .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse())
> >>
> >>
> >> will let you know my findings..
> >>
> >> As always, thanks for all your help.
> >>
> >> Thanks,
> >> Rishi
> >>
> >>
> >> On Tue, Apr 11, 2017 at 4:18 PM, Rishi Yagnik 
> >> wrote:
> >>
> >>> Hi Val,
> >>>
> >>> I will build it from master s and let you know by tomorrow.
> >>>
> >>> Thanks,
> >>>
> >>>
> >>> On Tue, Apr 11, 2017 at 3:53 PM, Valentin Kulichenko <
> >>> valentin.kuliche...@gmail.com> wrote:
> >>>
>  Hi Rishi,
> 
>  What was the issue with the HttpSessionCsrfTokenRepository? I didn't
> >> have
>  any problems after I added code you provided.
> 
>  The fix for [1] is already in master. Can you try building from there
> >> and
>  check if everything works fine for you?
> 
>  [1] https://issues.apache.org/jira/browse/IGNITE-4948
> 
>  -Val
> 
>  On Sat, Mar 18, 2017 at 5:15 PM, Denis Magda 
> >> wrote:
> 
> > Somewhere in April. This will be clarified on the dev list soon.
> >
> > On Saturday, March 18, 2017, Rishi Yagnik 
>  wrote:
> >
> >> Thanks, Val.
> >>
> >> When are we going to release Ignite 2.0 ? June ??
> >>
> >> Thanks,
> >>
> >> On Sat, Mar 18, 2017 at 6:02 AM, Valentin Kulichenko <
> >> valentin.kuliche...@gmail.com > wrote:
> >>
> >>> Denis,
> >>>
> >>> Yes, this should be possible. I will try to finalize the fix asap.
> >>>
> >>> -Val
> >>>
> >>> On Fri, Mar 17, 2017 at 7:46 PM, Denis Magda  >> > wrote:
> >>>
>  Val,
> 
>  Will it be possible to incorporate the fix into the nearest 2.0
> >> release?
> 
>  —
>  Denis
> 
> > On Mar 17, 2017, at 11:43 AM, Rishi Yagnik <
>  rishiyag...@gmail.com
> >> >
>  wrote:
> >
> > Hi Val,
> >
> > Hope you are well, any update on web session clustering.
> >
> > Thanks,
> > Rishi
> >
> > On Sat, Mar 11, 2017 at 12:29 PM, Rishi Yagnik <
> >> rishiyag...@gmail.com >
> > wrote:
> >
> >> Hi Val,
> >>
> >> Thanks looking forward for the fix..
> >>
> >> Take Care,
> >> Rishi
> >>
> >>> On Mar 11, 2017, at 11:31 AM, Valentin Kulichenko <
> >> valentin.kuliche...@gmail.com > wrote:
> >>>
> >>> Hi Rishi,
> >>>
> >>> I want to fix the bug first. It takes a bit longer than I
> > thought,
> >>> but
>  I
> >>> should finish it over the weekend.
> >>>
> >>> -Val
> >>>
>  On Fri, Mar 10, 2017 at 4:13 AM, Rishi Yagnik <
> >>> 

[jira] [Created] (IGNITE-4977) Remove BinaryIdentityResolvers mentioning from the documentation

2017-04-13 Thread Denis Magda (JIRA)
Denis Magda created IGNITE-4977:
---

 Summary: Remove BinaryIdentityResolvers mentioning from the 
documentation
 Key: IGNITE-4977
 URL: https://issues.apache.org/jira/browse/IGNITE-4977
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Denis Magda


{{BinaryIdentityResolvers}} are no longer supported. Refresh the whole 
documentation where they can be mentioned.

[~ptupitsyn], [~isapego], please do the same for .NET and C++ whenever required.



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


[jira] [Created] (IGNITE-4976) Document C++ Continuous Queries Remote Filters

2017-04-13 Thread Denis Magda (JIRA)
Denis Magda created IGNITE-4976:
---

 Summary: Document C++ Continuous Queries Remote Filters
 Key: IGNITE-4976
 URL: https://issues.apache.org/jira/browse/IGNITE-4976
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Igor Sapego


[~isapego], please document CQ remote filters feature (IGNITE-3575) and assign 
the ticket on me and Prachi for the final modifications.



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


[jira] [Created] (IGNITE-4975) Update Hibernate documentation (Hibernate 5 addition, discontinue of binary resolvers)

2017-04-13 Thread Denis Magda (JIRA)
Denis Magda created IGNITE-4975:
---

 Summary: Update Hibernate documentation (Hibernate 5 addition, 
discontinue of binary resolvers)
 Key: IGNITE-4975
 URL: https://issues.apache.org/jira/browse/IGNITE-4975
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Valentin Kulichenko


In Apache Ignite 2.0 there are at least two updates related to Hibernate 
integration that have to be documented:
* Hibernate 5 Support (IGNITE-1794)
* BinaryIdentityResolvers are discontinued and can't as a workaround 
(https://apacheignite-mix.readme.io/docs/hibernate-l2-cache#section-l2-cache-configuration)
 for Hibernate {{CacheKey}} serialization (IGNITE-3429)

[~vkulichenko], could help out and refine Hibernate doc taking into account 2 
points above? Here is a hidden page for the modifications:
https://dash.readme.io/project/apacheignite-mix/v1.9/docs/hibernate-l2-cache-20



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


[jira] [Created] (IGNITE-4974) Document .NET dynamically registered classes

2017-04-13 Thread Denis Magda (JIRA)
Denis Magda created IGNITE-4974:
---

 Summary: Document .NET dynamically registered classes
 Key: IGNITE-4974
 URL: https://issues.apache.org/jira/browse/IGNITE-4974
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Pavel Tupitsyn


[~ptupitsyn], please document modifications related to .NET dynamically 
registered classes (IGNITE-2703) and assign the ticket on me and Prachi for 
final polishment.



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


[jira] [Created] (IGNITE-4973) Document .NET Plugin System

2017-04-13 Thread Denis Magda (JIRA)
Denis Magda created IGNITE-4973:
---

 Summary: Document .NET Plugin System
 Key: IGNITE-4973
 URL: https://issues.apache.org/jira/browse/IGNITE-4973
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Pavel Tupitsyn


[~ptupitsyn], please document .NET plugin system (IGNITE-2940) with the usage 
hints whenever applicable.

As usual, assign on me and Prachi for the final review.



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


[jira] [Created] (IGNITE-4972) Document updated async API

2017-04-13 Thread Denis Magda (JIRA)
Denis Magda created IGNITE-4972:
---

 Summary: Document updated async API
 Key: IGNITE-4972
 URL: https://issues.apache.org/jira/browse/IGNITE-4972
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Vladimir Ozerov


Ignite async API was significantly simplified and refined in Apache Ignite 2.0 
(IGNITE-4475). The changes have to be documented on readme.io.

[~vozerov], [~taras.ledkov], please decide who will document the changes and 
assign the ticket on me for the final review. This is a 2.0 copy of an existing 
page ready for the modification:
https://dash.readme.io/project/apacheignite/v1.9/docs/asynchronous-support-20





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


[jira] [Created] (IGNITE-4971) Document how heartbeats are issued across the cluster ring

2017-04-13 Thread Denis Magda (JIRA)
Denis Magda created IGNITE-4971:
---

 Summary: Document how heartbeats are issued across the cluster ring
 Key: IGNITE-4971
 URL: https://issues.apache.org/jira/browse/IGNITE-4971
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Denis Magda


{{TcpDiscoverySpi.heartbeatsFrequency}} was removed from the API (IGNITE-4799). 
Let's update TcpDiscoverySpi page and explain how the heartbeats are issued 
across the cluster ring.
https://dash.readme.io/project/apacheignite/v1.9/docs/cluster-configuration-20




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


[jira] [Created] (IGNITE-4970) Document all transactional methods

2017-04-13 Thread Denis Magda (JIRA)
Denis Magda created IGNITE-4970:
---

 Summary: Document all transactional methods
 Key: IGNITE-4970
 URL: https://issues.apache.org/jira/browse/IGNITE-4970
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Denis Magda
Priority: Minor


Refer to IGNITE-4795 to get a list of transactional methods that have to be 
documented on: 
https://dash.readme.io/project/apacheignite/v1.9/docs/transactions-20



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


[jira] [Created] (IGNITE-4969) Document all available thread pools including custom ones

2017-04-13 Thread Denis Magda (JIRA)
Denis Magda created IGNITE-4969:
---

 Summary: Document all available thread pools including custom ones
 Key: IGNITE-4969
 URL: https://issues.apache.org/jira/browse/IGNITE-4969
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Vladimir Ozerov


In Apache Ignite 2.0 we introduced custom thread pools API that can be used 
along with Compute Grid.

Having this it makes sense to document all the pools we have:
* system
* public
* marshalling
* service
* custom
* etc.

[~vozerov], could you or someone who developed the custom pools document them 
there?
https://dash.readme.io/project/apacheignite/v1.9/docs/thread-pools

After that reassign the ticket on me and I'll document the rest of the pools.



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


[jira] [Created] (IGNITE-4967) Document Index related commands of DDL

2017-04-13 Thread Denis Magda (JIRA)
Denis Magda created IGNITE-4967:
---

 Summary: Document Index related commands of DDL
 Key: IGNITE-4967
 URL: https://issues.apache.org/jira/browse/IGNITE-4967
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Vladimir Ozerov
Priority: Critical


The first set of DDL commands is released in Apache Ignite 2.0. It will be 
possible to define and alter indexes using standard DDL statements 
(IGNITE-4565).

[~vozerov], [~al.psc], please decide who will document this capability:
https://dash.readme.io/project/apacheignite/v1.9/docs/distributed-ddl

Assign the ticket to me for final modifications because we will be required to 
update "schema and indexes" pages somehow (I'll do that):
https://apacheignite.readme.io/docs/indexes




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


[jira] [Created] (IGNITE-4966) Document SQL index hints and merge sort capabilities

2017-04-13 Thread Denis Magda (JIRA)
Denis Magda created IGNITE-4966:
---

 Summary: Document SQL index hints and merge sort capabilities
 Key: IGNITE-4966
 URL: https://issues.apache.org/jira/browse/IGNITE-4966
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Denis Magda


Document the following:
* SQL hints usage (IGNITE-4594)
* Merge sort (IGNITE-3013)



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


[jira] [Created] (IGNITE-4965) Document enum fileds handling and changes with 'select * ...' in SQL

2017-04-13 Thread Denis Magda (JIRA)
Denis Magda created IGNITE-4965:
---

 Summary: Document enum fileds handling and changes with 'select * 
...' in SQL 
 Key: IGNITE-4965
 URL: https://issues.apache.org/jira/browse/IGNITE-4965
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Denis Magda


Document the following:
* enum fields handling in SQL (IGNITE-3596)
* _key and _val are no longer returned in "select *..." result set (IGNITE-3487)



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


[GitHub] ignite pull request #1791: Ignite 4927

2017-04-13 Thread abeliak
GitHub user abeliak opened a pull request:

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

Ignite 4927

Don't merge

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

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

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

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


commit b8cb82de65a529040ea18b0dc03fa7109c69bb4a
Author: Vasiliy Sisko 
Date:   2016-12-29T07:48:45Z

IGNITE-4442 Implemented cache affinity configuration.

(cherry picked from commit f4a1e6c)

commit 852f03829c997883376245e3515e47822e9012eb
Author: Andrey Novikov 
Date:   2017-01-11T09:34:23Z

Merge branches 'ignite-1.7.5' and 'web-console-production' of 
https://github.com/gridgain/apache-ignite into web-console-production

commit d3e2e0c5574f7677645e73e1fbafaee3563895f1
Author: Andrey Novikov 
Date:   2017-01-25T07:27:01Z

Merge branches 'ignite-1.7.6' and 'web-console-production' of 
https://github.com/gridgain/apache-ignite into web-console-production

commit 295f80d10da02692540435d46961a9c3cca99b3c
Author: Andrey Novikov 
Date:   2017-01-25T06:58:57Z

IGNITE-4520 Added credential request for authentication on proxy.

(cherry picked from commit ef04f35)

commit faa20530a707014ac34477cba8adaaa4b67de1bb
Author: Andrey Novikov 
Date:   2017-01-25T09:48:05Z

IGNITE-1596 Fixed version sort.

(cherry picked from commit 128ba07)

commit 1b3bbdb1758eb19c755dabcb5fe329529fa0f378
Author: Andrey Novikov 
Date:   2017-01-27T04:30:49Z

IGNITE-4622 Fixed generation in domain model for cache store.

(cherry picked from commit 43007d5)

commit a8355feef630a5c8c4edbe02224c8325dd5952d3
Author: Andrey Novikov 
Date:   2017-02-03T04:58:43Z

IGNITE-4610 Added more informative message.

(cherry picked from commit 9ff2a8f)

commit 94d8a6fc0a61bb3046e2ebd8b3cbffb8917c2b6a
Author: Andrey Novikov 
Date:   2017-02-08T04:43:22Z

IGNITE-4472 Added user activities in Web Console.

(cherry picked from commit 26ee9c2)

commit b571fd40f009709718bce0c969d47b62be06b8f6
Author: Andrey Novikov 
Date:   2017-02-08T10:05:08Z

IGNITE-4472 Added user activities in Web Console.

(cherry picked from commit 26ee9c2)

commit db48f545a83bb72cded77d8269fe4f8820e8380f
Author: Andrey Novikov 
Date:   2017-02-10T08:55:05Z

IGNITE-4678 Web Console: Implemented demo load as service.

(cherry picked from commit a600caf)

commit e4b54c985f256478ae2cae23b423d9b8e0842df8
Author: Andrey Novikov 
Date:   2017-02-13T02:48:50Z

Merge branch 'ignite-1.8.3' of https://github.com/gridgain/apache-ignite 
into web-console-production

commit 2d6735a20ac8009d1ac3f003da4fcd319271bd71
Author: Alexey Kuznetsov 
Date:   2017-02-09T09:44:41Z

IGNITE-4676 Fixed hang if closure executed nested internal task with 
continuation. Added test.

(cherry picked from commit e7a5307)

commit d307e2eced1fd10b007ee08c3dd113e7bb4f22ba
Author: Andrey Novikov 
Date:   2017-02-13T10:35:29Z

IGNITE-4687 Added pool to process REST request in Web Agent.

(cherry picked from commit 262a341)

commit 8874f99f44dc2edf08a525619edb49d5db70b938
Author: dkarachentsev 
Date:   2017-02-14T15:44:57Z

IGNITE-4641 - Refresh client attributes during reconnect

commit ca5956bedfc0c3bd18290c64b6a6c2e3f114a440
Author: Andrey Novikov 
Date:   2017-02-14T16:28:06Z

IGNITE-4472 UI fix, minor fixes

(cherry picked from commit 79e1e53)

commit db9252c9588c671279664484bb8c397312d265e6
Author: Andrey Novikov 
Date:   2017-02-15T09:08:57Z

IGNITE-4678 Node version in range.

(cherry picked from commit 2cfd55d)

commit 58c0c49d31605bf4608e7ee97099b75b324a782f
Author: Andrey Novikov 
Date:   2017-02-16T03:41:30Z

IGNITE-4472 Fixed became this user.

(cherry picked from commit ee832e4)

commit 2ccbf32ea3ecaff1068832accf37235a32734b4b
Author: Andrey Novikov 
Date:   2017-02-16T07:22:22Z

IGNITE-4472 Minor UI fix.

(cherry picked from commit 97c7ed7)

commit ef4886d5be7c708b917e97b1cd5fd766b2ad8450
Author: Andrey Novikov 
Date:   2017-02-16T11:38:40Z

IGNITE-4472 Minor UI fix.

(cherry picked from commit d4efbf3)

commit 05788b3188b30b5a3b39a75fe66301e03658408f
Author: Andrey V. Mashenkov 
Date:   2017-02-17T09:14:53Z

IGNITE-3429: 

[GitHub] ignite pull request #1784: Ignite 4927

2017-04-13 Thread abeliak
Github user abeliak closed the pull request at:

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


---
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: Adding ML to Ignite, IGNITE-4572

2017-04-13 Thread Denis Magda
Hi Oleg,

That’s great, thanks. I’ve created a JIRA ticket for this task and assigned on 
Nikita for now. Please create an account for yourself and reassign the ticket 
if needed:
https://issues.apache.org/jira/browse/IGNITE-4964

Plus, there is an invisible page on readme.io  created for 
you where you can document everything right away:
https://dash.readme.io/project/apacheignite/v1.9/docs/distributed-algebra

I’ll grant you editor rights to the readme today, you’ll receive a notification.

—
Denis
 
> On Apr 13, 2017, at 9:33 AM, oignatenko  wrote:
> 
> Yury, Denis - me and Nikita are going to take care of readme.io docs.
> 
> I plan to start on this tomorrow, will keep you posted on the progress.
> 
> Current plan is to briefly introduce new package and examples and explain
> how to run examples and possibly unit tests.
> 
> With regards to build details, this will depend on how accurate is the
> description in project readme files: I am currently running build check to
> verify everything in details. If readme files are okay we will likely just
> refer readers to these for more details. In case if there are any
> discrepancies we will provide concrete build details at readme.io.
> 
> If you have anything to add or correct in above plan please let me know.
> 
> regards, Oleg
> 
> Yury Babak wrote
>> As far as I know Nikita wants to provide this documentation.
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://apache-ignite-developers.2346864.n4.nabble.com/Adding-ML-to-Ignite-IGNITE-4572-tp13936p16603.html
> Sent from the Apache Ignite Developers mailing list archive at Nabble.com.



[jira] [Created] (IGNITE-4964) Document Machine Learning Grid (Distributed Algebra Implementation)

2017-04-13 Thread Denis Magda (JIRA)
Denis Magda created IGNITE-4964:
---

 Summary: Document Machine Learning Grid (Distributed Algebra 
Implementation)
 Key: IGNITE-4964
 URL: https://issues.apache.org/jira/browse/IGNITE-4964
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Nikita Ivanov


In Apache Ignite 2.0 we introduce support for distributed algebra on top of 
Ignite. This considered to be a foundation of Ignite's Machine Learning 
framework discussed here:
http://apache-ignite-developers.2346864.n4.nabble.com/Adding-ML-to-Ignite-IGNITE-4572-td13936.html

Let's make an overview of the current implementation, its usage, and refer to 
developed examples as a part of the readme.io documentation. Here is an 
invisible page created for this purpose:
https://dash.readme.io/project/apacheignite/v1.9/docs/distributed-algebra

Please assign the ticket on [~dmagda] for the final review.



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


[jira] [Created] (IGNITE-4963) Document cache store metrics based on page memory

2017-04-13 Thread Denis Magda (JIRA)
Denis Magda created IGNITE-4963:
---

 Summary: Document cache store metrics based on page memory 
 Key: IGNITE-4963
 URL: https://issues.apache.org/jira/browse/IGNITE-4963
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Denis Magda


There is no documentation for the metrics. At the first phase let's document 
cache metrics altered as a part of this task - IGNITE-4536



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


[jira] [Created] (IGNITE-4962) Document New Eviction and Expiration Policies

2017-04-13 Thread Denis Magda (JIRA)
Denis Magda created IGNITE-4962:
---

 Summary: Document New Eviction and Expiration Policies 
 Key: IGNITE-4962
 URL: https://issues.apache.org/jira/browse/IGNITE-4962
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Denis Magda
Priority: Critical


This following is intended to be done as a part of this ticket:
* refine eviction policy documentation 
(https://apacheignite.readme.io/docs/evictions). Take a look at the changes - 
IGNITE-4534
* make sure everything left unchanged with the expiration policy 
(https://apacheignite.readme.io/docs/expiry-policies)



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


[jira] [Created] (IGNITE-4961) Document Page Memory API, Architecture and Behavior

2017-04-13 Thread Denis Magda (JIRA)
Denis Magda created IGNITE-4961:
---

 Summary: Document Page Memory API, Architecture and Behavior
 Key: IGNITE-4961
 URL: https://issues.apache.org/jira/browse/IGNITE-4961
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Denis Magda
Priority: Blocker


The goal of this ticket is to provide extensive documentation around the new 
page memory architecture introduced in Apache Ignite 2.0.

Refer to IGNITE-3477 and do the following as a part of this ticket:
* page memory architecture, advantages, and usage.
* page memory policies (IGNITE-4960).
* rework or discontinue Off-Heap Memory page 
(https://apacheignite.readme.io/docs/off-heap-memory) that lists all the memory 
tiers supported in versions 1.x. For instance, the swap space is no longer 
available (IGNITE-4736) and the Java heap is no more a default one and used 
just as a cache of a page memory (IGNITE-4535).

Once the Java documentation is ready, assign the ticket to [~ptupitsyn] and 
[~isapego] who will create .NET and C++ counterparts following a Java template.



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


[jira] [Created] (IGNITE-4960) Apache Ignite 2.0 Documentation

2017-04-13 Thread Denis Magda (JIRA)
Denis Magda created IGNITE-4960:
---

 Summary: Apache Ignite 2.0 Documentation
 Key: IGNITE-4960
 URL: https://issues.apache.org/jira/browse/IGNITE-4960
 Project: Ignite
  Issue Type: Task
Reporter: Denis Magda
Assignee: Denis Magda
Priority: Critical
 Fix For: 2.0


This is an umbrella ticket for all the documentation that has to be prepared or 
updated as a part of Apache Ignite 2.0 release.



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


Re: Adding ML to Ignite, IGNITE-4572

2017-04-13 Thread oignatenko
Yury, Denis - me and Nikita are going to take care of readme.io docs.

I plan to start on this tomorrow, will keep you posted on the progress.

Current plan is to briefly introduce new package and examples and explain
how to run examples and possibly unit tests.

With regards to build details, this will depend on how accurate is the
description in project readme files: I am currently running build check to
verify everything in details. If readme files are okay we will likely just
refer readers to these for more details. In case if there are any
discrepancies we will provide concrete build details at readme.io.

If you have anything to add or correct in above plan please let me know.

regards, Oleg

Yury Babak wrote
> As far as I know Nikita wants to provide this documentation.





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


[GitHub] ignite pull request #1790: IGNITE-3488

2017-04-13 Thread gvvinblade
GitHub user gvvinblade opened a pull request:

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

IGNITE-3488



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

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

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

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


commit ba95cc4a122e6c10057f53c7aa4646675996c68b
Author: Igor Seliverstov 
Date:   2017-04-13T11:48:41Z

[IGNITE-3488] Prohibit null as name in all the components (cache name first 
of all).

commit fc501297b2209a3f9ddd0a641790501472fb3612
Author: Igor Seliverstov 
Date:   2017-04-13T15:45:44Z

Merge remote-tracking branch 'professional/ignite-3488'

commit 8d1e2b315cf20d0f09ecaff68c33d94135956011
Author: Igor Seliverstov 
Date:   2017-04-13T11:48:41Z

[IGNITE-3488] Prohibit null as name in all the components (cache name first 
of all).

commit 10395f6bd6aea372ce29e59a323e2a7f68bdc11f
Author: Igor Seliverstov 
Date:   2017-04-13T15:44:00Z

[IGNITE-3488] Prohibit null as name in all the components (cache name first 
of all).




---
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 #1789: IGNITE-3524 IGFS: Do not allow nulls for FileSyst...

2017-04-13 Thread tledkov-gridgain
GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-3524  IGFS: Do not allow nulls for FileSystemConfiguration.name



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

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

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

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


commit cc5de23a26ba3cb93a209e66741e114db5228343
Author: tledkov-gridgain 
Date:   2017-04-13T10:18:07Z

IGNITE-3524 IGFS: Do not allow nulls for FileSystemConfiguration.name

commit 05eca2e19f9036cac0198eef7da74674ff2623da
Author: tledkov-gridgain 
Date:   2017-04-13T14:10:50Z

IGNITE-3524 IGFS: Do not allow nulls for FileSystemConfiguration.name




---
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: Move documentation from readme.io to GitHub pages

2017-04-13 Thread Dmitriy Setrakyan
On Wed, Apr 12, 2017 at 8:52 PM, Konstantin Boudnik  wrote:

> I hate to be that guy, but mentors warned this very project no to do
> this in the first place. At least once [1] on the dev@, and a few
> times off-line
>

Cos, no doubt this had come up before (after all, we did have very good
mentors during the incubation process).

Unfortunately, for tasks like this it is never a good time. I hope someone
in the community picks it up, or at least gets started on it.


[jira] [Created] (IGNITE-4959) Possible slight memory leak in free list

2017-04-13 Thread Ivan Rakov (JIRA)
Ivan Rakov created IGNITE-4959:
--

 Summary: Possible slight memory leak in free list
 Key: IGNITE-4959
 URL: https://issues.apache.org/jira/browse/IGNITE-4959
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Affects Versions: 2.0
Reporter: Ivan Rakov
Assignee: Alexey Goncharuk


To reproduce, run PageEvictionMultinodeTest (any eviction mode), set ENTRIES to 
Integer.MAX_VALUE.
Observations:
1) After a few minutes of test running, number of allocated pages looks like a 
constant (a bit more than eviciton threshold, 90% by default). This is expected 
behaviour with enabled page eviction.
2) More precise measurement shows that there's slow linear growth of allocated 
pages number, literally 10-20 pages per minute.
3) Number of pages with type T_PAGE_LIST_NODE grows, number of all other pages 
remains constant.
4) Though, total number of pages in free list remains constant (with minor 
fluctuations).
We have to find out whether this process has a saturation point, after which 
pages number stop growing. Otherwise, it's a memory leak and should be fixed.



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


[jira] [Created] (IGNITE-4958) Make data pages recyclable into index/meta/etc pages and vice versa

2017-04-13 Thread Ivan Rakov (JIRA)
Ivan Rakov created IGNITE-4958:
--

 Summary: Make data pages recyclable into index/meta/etc pages and 
vice versa
 Key: IGNITE-4958
 URL: https://issues.apache.org/jira/browse/IGNITE-4958
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Affects Versions: 2.0
Reporter: Ivan Rakov
Assignee: Alexey Goncharuk


Recycling for data pages is disabled for now. Empty data pages are accumulated 
in FreeListImpl#emptyDataPagesBucket, and can be reused only as data pages 
again. What has to be done:
* Empty data pages should be recycled into reuse bucket
* We should check reuse bucket first before allocating a new data page
* MemoryPolicyConfiguration#emptyPagesPoolSize should be removed



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


[GitHub] ignite pull request #1788: IGNITE-4952 swap/unswap functionality was removed

2017-04-13 Thread sergey-chugunov-1985
GitHub user sergey-chugunov-1985 opened a pull request:

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

IGNITE-4952 swap/unswap functionality was removed



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

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

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

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


commit f418736964f96d2215193c63c1e7c04f2bc755ef
Author: Sergey Chugunov 
Date:   2017-04-12T14:31:37Z

IGNITE-4952 obsolete Event Types were removed, onSwap/onUnswap methods were 
removed from Query processor/manager as well




---
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: [jira] [Commented] (IGNITE-4052) Add ability to set up users for MESOS

2017-04-13 Thread Nikolai Tikhonov
Vadim,

I've left comment in the ticket.

On Wed, Apr 12, 2017 at 3:00 PM, Вадим Опольский 
wrote:

> Hello guys!
>
> Nikolay, I looked at cassandra mesos integration, but cant find how to
> test ability to configure mesos and user via system env properties. I will
> continue to search in another projects which use Mesos.
>
> Review please pull request - https://github.com/vadopolski/ignite/pull/2.
> It contains new test and method for setting system environments.
>
> Can you close issue https://issues.apache.org/jira/browse/IGNITE-4052 and
> open new, about testing Mesos Integration.
>
> Vadim Opolski
>
> 2017-04-03 12:13 GMT+03:00 Nikolay Tikhonov (JIRA) :
>
>>
>> [ https://issues.apache.org/jira/browse/IGNITE-4052?page=com.a
>> tlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&
>> focusedCommentId=15953167#comment-15953167 ]
>>
>> Nikolay Tikhonov commented on IGNITE-4052:
>> --
>>
>> [~javaller],
>> For example you can look at cassandra mesos integration
>> https://github.com/mesosphere/dcos-cassandra-service/blob/5d
>> 6d15e646f1df2fa10fa98d91993d3a6b4719c4/cassandra-commons/src
>> /main/java/com/mesosphere/dcos/cassandra/common/config/ServiceConfig.java.
>> List of application which use Mesos not secret and can be found on official
>> mesos site http://mesos.apache.org/documentation/latest/frameworks. ;)
>>
>> I'm really don't understand how the libs can help you. Could you clarify
>> it?
>>
>> > Add ability to set up users for MESOS
>> > -
>> >
>> > Key: IGNITE-4052
>> > URL: https://issues.apache.org/jira/browse/IGNITE-4052
>> > Project: Ignite
>> >  Issue Type: Improvement
>> >  Components: general
>> >Affects Versions: 1.7
>> >Reporter: Nikolay Tikhonov
>> >Assignee: Vadim Opolski
>> >Priority: Trivial
>> >
>> > In current implementation Ignite Mesos Framework connects to MESOS
>> cluster via current user. Need to add ability to configure this parameters
>> via system env properties. Also need to add properties for mesos role.
>> > See org/apache/ignite/mesos/IgniteFramework.java:537
>>
>>
>>
>> --
>> This message was sent by Atlassian JIRA
>> (v6.3.15#6346)
>>
>
>


Re: Synchronize method across Ignite cluster

2017-04-13 Thread Anton Vinogradov
>> Lock lock = cache.lock(key); - works only
>> with CacheAtomicityMode.TRANSACTIONAL
Correct

>> Does cache-locks work across all nodes of Ignite-cluster?
Yes

>> what an approach will be the best for use
>> within IGNITE-4211.
EntryProcessor is the best case, but, seems, it can't be used due to Spring
AOPs.

On Thu, Apr 13, 2017 at 4:15 PM, Vyacheslav Daradur 
wrote:

> Anton, you all know for what I need it))
>
> As I understand:
> Lock lock = cache.lock(key); - works only
> with CacheAtomicityMode.TRANSACTIONAL
>
> Does cache-locks work across all nodes of Ignite-cluster?
>
> Can you give me some advice: what an approach will be the best for use
> within IGNITE-4211. (you know the context of this task)
>
>
> 2017-04-13 16:06 GMT+03:00 Anton Vinogradov :
>
> > Vyacheslav,
> >
> > Explicit cache locks, DataStructures (eg. reentrant locks), transactions,
> > etc.
> > We have all of them and even more :)
> >
> > On Thu, Apr 13, 2017 at 3:54 PM, Vyacheslav Daradur  >
> > wrote:
> >
> > > Hi Igniters!
> > >
> > > I need to synchronize a method across a Ignite cluster, which work with
> > > IgniteCache.
> > >
> > > Does Ignite provide any tools for?
> > >
> > > For example:
> > > ***
> > > Lock lock = cache.lock(key);
> > > lock.lock();
> > >
> > > try {
> > >  // todo somethink
> > > }
> > > finally {
> > > lock.unlock();
> > > }
> > > ***
> > >
> > > --
> > > Best Regards, Vyacheslav
> > >
> >
>
>
>
> --
> Best Regards, Vyacheslav
>


Re: IgniteSemaphore and failoverSafe flag

2017-04-13 Thread Dmitry Karachentsev

Thanks a lot!

12.04.2017 16:35, Vladisav Jelisavcic пишет:

Hi Dmitry,

sure, I made a fix, take a look at the PR and the comments in the ticket.

Best regards,
Vladisav

On Tue, Apr 11, 2017 at 3:00 PM, Dmitry Karachentsev 
> wrote:


Hi Vladislav,

Thanks for your contribution! But it seems doesn't fix related
tickets, in particular [1].
Could you please take a look?

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


Thanks!

06.04.2017 16:27, Vladisav Jelisavcic пишет:

Hey Dmitry,

sorry for the late reply, I'll try to bake a pr later during the day.

Best regards,
Vladisav



On Tue, Apr 4, 2017 at 11:05 AM, Dmitry Karachentsev
>
wrote:

Hi Vladislav,

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

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


Thanks!

-Dmitry.



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

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

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

Hi everyone,

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

Best regards,
Vladisav



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

Guys,

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

is

the following:

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

guarded

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

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

Am I missing something?

-Val

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

dsetrak...@apache.org 

wrote:

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

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

user

may

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

Yes, this is exactly my point.

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

for

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

re-created,

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

two

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

lock())

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

the


Re: Synchronize method across Ignite cluster

2017-04-13 Thread Vyacheslav Daradur
Anton, you all know for what I need it))

As I understand:
Lock lock = cache.lock(key); - works only
with CacheAtomicityMode.TRANSACTIONAL

Does cache-locks work across all nodes of Ignite-cluster?

Can you give me some advice: what an approach will be the best for use
within IGNITE-4211. (you know the context of this task)


2017-04-13 16:06 GMT+03:00 Anton Vinogradov :

> Vyacheslav,
>
> Explicit cache locks, DataStructures (eg. reentrant locks), transactions,
> etc.
> We have all of them and even more :)
>
> On Thu, Apr 13, 2017 at 3:54 PM, Vyacheslav Daradur 
> wrote:
>
> > Hi Igniters!
> >
> > I need to synchronize a method across a Ignite cluster, which work with
> > IgniteCache.
> >
> > Does Ignite provide any tools for?
> >
> > For example:
> > ***
> > Lock lock = cache.lock(key);
> > lock.lock();
> >
> > try {
> >  // todo somethink
> > }
> > finally {
> > lock.unlock();
> > }
> > ***
> >
> > --
> > Best Regards, Vyacheslav
> >
>



-- 
Best Regards, Vyacheslav


[GitHub] ignite pull request #1779: IGNITE-3018 Cache affinity calculation is slow wi...

2017-04-13 Thread tledkov-gridgain
Github user tledkov-gridgain closed the pull request at:

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


---
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: Synchronize method across Ignite cluster

2017-04-13 Thread Anton Vinogradov
Vyacheslav,

Explicit cache locks, DataStructures (eg. reentrant locks), transactions,
etc.
We have all of them and even more :)

On Thu, Apr 13, 2017 at 3:54 PM, Vyacheslav Daradur 
wrote:

> Hi Igniters!
>
> I need to synchronize a method across a Ignite cluster, which work with
> IgniteCache.
>
> Does Ignite provide any tools for?
>
> For example:
> ***
> Lock lock = cache.lock(key);
> lock.lock();
>
> try {
>  // todo somethink
> }
> finally {
> lock.unlock();
> }
> ***
>
> --
> Best Regards, Vyacheslav
>


[jira] [Created] (IGNITE-4957) First join query execution in client mode takes too long when there are many caches on remote nodes

2017-04-13 Thread Alexandr Fedotov (JIRA)
Alexandr Fedotov created IGNITE-4957:


 Summary: First join query execution in client mode takes too long 
when there are many caches on remote nodes
 Key: IGNITE-4957
 URL: https://issues.apache.org/jira/browse/IGNITE-4957
 Project: Ignite
  Issue Type: Improvement
  Components: SQL
Affects Versions: 1.9
Reporter: Alexandr Fedotov
 Fix For: 2.1


When there are many caches deployed on server nodes and a query containing 
joins is executed on a client for the first time it takes much time to complete 
compared to the following executions.

If caches aren't enabled locally then the first query tries to load all the 
missing caches by calling
{{org.apache.ignite.internal.processors.cache.GridCacheProcessor#createMissingCaches}}
createMissingCaches internally sends a request per each registered but not 
enabled cache.
Performance could be improved by performing a batch request.




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


Re: IGNITE-2741 - spring session design

2017-04-13 Thread Rishi Yagnik
Val,

Yes I would provide you the exact steps today and I will also test it in 
cluster environment.

The local environment is working as expected with the fix.

Take Care,
Rishi

> On Apr 13, 2017, at 2:18 AM, Valentin Kulichenko 
>  wrote:
> 
> Rishi,
> 
> Can you tell exact steps to reproduce? It's working for me in my
> environment.
> 
> Do I understand correctly that apart from the token issue, it works fine
> with new version?
> 
> -Val
> 
> On Wed, Apr 12, 2017 at 10:00 PM, Rishi Yagnik 
> wrote:
> 
>> Val,
>> 
>> I build it from master s and was able to integrate with our app, but as I
>> mentioned to you previously, I see the XSRF-Token errors in debug log,
>> 
>> [DEBUG] [XNIO-2 task-4] org.springframework.security.web.FilterChainProxy
>> -
>> /app/xxx/yyy/zz/A at position 3 of 13 in additional filter chain; firing
>> Filter: 'HeaderWriterFilter'
>> [DEBUG] [XNIO-2 task-4] org.springframework.security.web.FilterChainProxy
>> -
>> /app/xxx/yyy/zz/A at position 4 of 13 in additional filter chain; firing
>> Filter: 'CsrfFilter'
>> 
>> [DEBUG] [XNIO-2 task-4] org.springframework.security.web.csrf.CsrfFilter -
>> Invalid CSRF token found for http://localhost:9002/app/xxx/yyy/zz/A
>> 
>> And, then after, CSRF filter does not like the session, redirects to /403
>> error.
>> 
>> Just wondering why the XSRF Token is not being saved in the session  ?
>> 
>> More debugging is require for sure..
>> 
>> of course there is a work around to the problem, I can just use Cookie
>> based Token repository to avoid this issue.
>> 
>> .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse())
>> 
>> 
>> will let you know my findings..
>> 
>> As always, thanks for all your help.
>> 
>> Thanks,
>> Rishi
>> 
>> 
>> On Tue, Apr 11, 2017 at 4:18 PM, Rishi Yagnik 
>> wrote:
>> 
>>> Hi Val,
>>> 
>>> I will build it from master s and let you know by tomorrow.
>>> 
>>> Thanks,
>>> 
>>> 
>>> On Tue, Apr 11, 2017 at 3:53 PM, Valentin Kulichenko <
>>> valentin.kuliche...@gmail.com> wrote:
>>> 
 Hi Rishi,
 
 What was the issue with the HttpSessionCsrfTokenRepository? I didn't
>> have
 any problems after I added code you provided.
 
 The fix for [1] is already in master. Can you try building from there
>> and
 check if everything works fine for you?
 
 [1] https://issues.apache.org/jira/browse/IGNITE-4948
 
 -Val
 
 On Sat, Mar 18, 2017 at 5:15 PM, Denis Magda 
>> wrote:
 
> Somewhere in April. This will be clarified on the dev list soon.
> 
> On Saturday, March 18, 2017, Rishi Yagnik 
 wrote:
> 
>> Thanks, Val.
>> 
>> When are we going to release Ignite 2.0 ? June ??
>> 
>> Thanks,
>> 
>> On Sat, Mar 18, 2017 at 6:02 AM, Valentin Kulichenko <
>> valentin.kuliche...@gmail.com > wrote:
>> 
>>> Denis,
>>> 
>>> Yes, this should be possible. I will try to finalize the fix asap.
>>> 
>>> -Val
>>> 
>>> On Fri, Mar 17, 2017 at 7:46 PM, Denis Magda > > wrote:
>>> 
 Val,
 
 Will it be possible to incorporate the fix into the nearest 2.0
>> release?
 
 —
 Denis
 
> On Mar 17, 2017, at 11:43 AM, Rishi Yagnik <
 rishiyag...@gmail.com
>> >
 wrote:
> 
> Hi Val,
> 
> Hope you are well, any update on web session clustering.
> 
> Thanks,
> Rishi
> 
> On Sat, Mar 11, 2017 at 12:29 PM, Rishi Yagnik <
>> rishiyag...@gmail.com >
> wrote:
> 
>> Hi Val,
>> 
>> Thanks looking forward for the fix..
>> 
>> Take Care,
>> Rishi
>> 
>>> On Mar 11, 2017, at 11:31 AM, Valentin Kulichenko <
>> valentin.kuliche...@gmail.com > wrote:
>>> 
>>> Hi Rishi,
>>> 
>>> I want to fix the bug first. It takes a bit longer than I
> thought,
>>> but
 I
>>> should finish it over the weekend.
>>> 
>>> -Val
>>> 
 On Fri, Mar 10, 2017 at 4:13 AM, Rishi Yagnik <
>>> rishiyag...@gmail.com >
>> wrote:
 
 Hi Val,
 
 Did you chance to look into session handling issue ?
 
 Thanks,
 
 On Mon, Mar 6, 2017 at 3:37 PM, Rishi Yagnik <
>> rishiyag...@gmail.com 
 
 wrote:
 
> Hi Val,
> 
> Do you think I can test a fix in 1.9 RC releases ? How are
 you
 planning
 to
> release a fix ?
> 
> Did you also look into problem where storing xsrf 

Synchronize method across Ignite cluster

2017-04-13 Thread Vyacheslav Daradur
Hi Igniters!

I need to synchronize a method across a Ignite cluster, which work with
IgniteCache.

Does Ignite provide any tools for?

For example:
***
Lock lock = cache.lock(key);
lock.lock();

try {
 // todo somethink
}
finally {
lock.unlock();
}
***

-- 
Best Regards, Vyacheslav


Re: IGNITE - 4760 ready for review

2017-04-13 Thread Вадим Опольский
Semyon, thanks for comments.

- I will change access type for created region.
- USE_STRUCTURED_CACHE property needs to store data in cache in a more
readable format. Without it I cant cast data from cache to String and
HashMap.
- I will add the same test for READ_WRITE access strategy.
- I will check code style rules.

Vadim


2017-04-13 15:05 GMT+03:00 Semyon Boikov :

> Hi Vadim,
>
> I added comments in JIRA. I'll apply the same fix for hibernate5 when fix
> is finalized.
>
> Thanks!
>
> On Thu, Apr 13, 2017 at 12:10 PM, Вадим Опольский 
> wrote:
>
>> Hi, guys!
>>
>> Semyon, have you had a time to review IGNITE-4760
>> https://github.com/apache/ignite/pull/1768 ?
>>
>> Is this fix actual for hibernate5 module?
>>
>> Vadim Opolski
>>
>> 2017-04-11 13:40 GMT+03:00 Semyon Boikov :
>>
>>> Thanks Vadim, I'll try to do review today.
>>>
>>> Semyon
>>>
>>> On Mon, Apr 10, 2017 at 8:15 PM, Вадим Опольский 
>>> wrote:
>>>
 Hello guys!

 Semyon, review please again. Test check corresponding IgniteCaches
 contain expected number of entries. Test fails for
 HibernateNonStrictAccessStrategy.
 And per-cache thread local in method threadLocalForCache fix this issue.

 https://github.com/apache/ignite/pull/1768/files

 Vadim Opolski


 2017-04-07 14:15 GMT+03:00 Semyon Boikov :

> Hi Vadim,
>
> Test does not look correct to me. I think test need check that
> corresponding IgniteCaches contain expected number of entries like
> 'testCacheUsage' does.
>
> Thanks
>
> On Wed, Apr 5, 2017 at 3:26 PM, Вадим Опольский 
> wrote:
>
>> 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 
>>
>>
>> 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/5aa25f3830fef14ac5
>> 07ed73872d62b2969a7411/modules/hibernate/src/main/java/org/a
>> pache/ignite/cache/hibernate/HibernateRegionFactory.java
>>
>> https://github.com/vadopolski/ignite/blob/5aa25f3830fef14ac5
>> 07ed73872d62b2969a7411/modules/hibernate/src/test/java/org/a
>> pache/ignite/cache/hibernate/HibernateL2CacheConfigurationSe
>> lfTest.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

[GitHub] ignite pull request #1205: IGNITE-4155 minor fixes to examples

2017-04-13 Thread sergey-chugunov-1985
Github user sergey-chugunov-1985 closed the pull request at:

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


---
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 #1744: Ignite 3477 master client offheap fix

2017-04-13 Thread sergey-chugunov-1985
Github user sergey-chugunov-1985 closed the pull request at:

https://github.com/apache/ignite/pull/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 #1754: Ignite 3477 client hash index fix

2017-04-13 Thread sergey-chugunov-1985
Github user sergey-chugunov-1985 closed the pull request at:

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


---
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 #1769: Ignite 3477 master CPP Win32 OOM fix

2017-04-13 Thread sergey-chugunov-1985
Github user sergey-chugunov-1985 closed the pull request at:

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


---
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 #1778: client reconnect fix

2017-04-13 Thread sergey-chugunov-1985
Github user sergey-chugunov-1985 closed the pull request at:

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


---
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 - 4760 ready for review

2017-04-13 Thread Semyon Boikov
Hi Vadim,

I added comments in JIRA. I'll apply the same fix for hibernate5 when fix
is finalized.

Thanks!

On Thu, Apr 13, 2017 at 12:10 PM, Вадим Опольский 
wrote:

> Hi, guys!
>
> Semyon, have you had a time to review IGNITE-4760
> https://github.com/apache/ignite/pull/1768 ?
>
> Is this fix actual for hibernate5 module?
>
> Vadim Opolski
>
> 2017-04-11 13:40 GMT+03:00 Semyon Boikov :
>
>> Thanks Vadim, I'll try to do review today.
>>
>> Semyon
>>
>> On Mon, Apr 10, 2017 at 8:15 PM, Вадим Опольский 
>> wrote:
>>
>>> Hello guys!
>>>
>>> Semyon, review please again. Test check corresponding IgniteCaches
>>> contain expected number of entries. Test fails for
>>> HibernateNonStrictAccessStrategy.
>>> And per-cache thread local in method threadLocalForCache fix this issue.
>>>
>>> https://github.com/apache/ignite/pull/1768/files
>>>
>>> Vadim Opolski
>>>
>>>
>>> 2017-04-07 14:15 GMT+03:00 Semyon Boikov :
>>>
 Hi Vadim,

 Test does not look correct to me. I think test need check that
 corresponding IgniteCaches contain expected number of entries like
 'testCacheUsage' does.

 Thanks

 On Wed, Apr 5, 2017 at 3:26 PM, Вадим Опольский 
 wrote:

> 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 
>
>
> 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/5aa25f3830fef14ac5
> 07ed73872d62b2969a7411/modules/hibernate/src/main/java/org/a
> pache/ignite/cache/hibernate/HibernateRegionFactory.java
>
> https://github.com/vadopolski/ignite/blob/5aa25f3830fef14ac5
> 07ed73872d62b2969a7411/modules/hibernate/src/test/java/org/a
> pache/ignite/cache/hibernate/HibernateL2CacheConfigurationSe
> lfTest.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
>> > 

[jira] [Created] (IGNITE-4956) Stabilize the test IgniteCacheLockPartitionOnAffinityRunAtomicCacheOpTest.testNotReservedTxCacheOp

2017-04-13 Thread Taras Ledkov (JIRA)
Taras Ledkov created IGNITE-4956:


 Summary: Stabilize  the test 
IgniteCacheLockPartitionOnAffinityRunAtomicCacheOpTest.testNotReservedTxCacheOp
 Key: IGNITE-4956
 URL: https://issues.apache.org/jira/browse/IGNITE-4956
 Project: Ignite
  Issue Type: Test
Affects Versions: 1.9
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.1






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


[GitHub] ignite pull request #1782: IGNITE-3581: CPP: Moved enums to separate structs

2017-04-13 Thread isapego
Github user isapego closed the pull request at:

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


---
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 #1787: IGNITE-2398 .NET: Change default mapper behavior

2017-04-13 Thread ptupitsyn
GitHub user ptupitsyn opened a pull request:

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

IGNITE-2398 .NET: Change default mapper behavior



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

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

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

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


commit 25e5a5417263e25f90d198b7afc86255c5bed7f2
Author: Pavel Tupitsyn 
Date:   2017-04-13T11:45:21Z

IGNITE-2398 .NET: Change default mapper behavior




---
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 #1777: IGNITE-2398 .NET: Change default mapper behavior

2017-04-13 Thread ptupitsyn
Github user ptupitsyn closed the pull request at:

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


---
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: Sorting fields of Binarilyzable objects on write

2017-04-13 Thread Dmitriy Setrakyan
Vova, can you give an example of when writing out of order would be the
only option?

On Thu, Apr 13, 2017 at 4:20 AM, Vladimir Ozerov 
wrote:

> Folks,
>
> If you restrict writes in certain order and conditions, Binarylizable
> interfaces turns into an unusable bullshit :-) Remember that not all binary
> objects participate in DML, and even if so, not all binary objects are
> cache keys. I think we should simply print a warning to log, informing user
> about potential problems if order is violated.
>
> On Thu, Apr 13, 2017 at 2:16 PM, Alexey Goncharuk <
> alexey.goncha...@gmail.com> wrote:
>
> > That is cool, completely forgot about it :)
> >
> > 2017-04-13 14:07 GMT+03:00 Pavel Tupitsyn :
> >
> > > Alexey, we can read fields in any order in non-raw mode.
> > > Dmitriy's suggestion would work.
> > >
> > > On Thu, Apr 13, 2017 at 1:56 PM, Alexey Goncharuk <
> > > alexey.goncha...@gmail.com> wrote:
> > >
> > > > Dmitriy,
> > > >
> > > > How would then reader determine which field to read (a and b could
> the
> > of
> > > > different size)? c in this case must be written first.
> > > >
> > > > 2017-04-13 0:29 GMT+03:00 Dmitriy Setrakyan :
> > > >
> > > > > Vladimir,
> > > > >
> > > > > Would this be valid?
> > > > >
> > > > > *void writeBinary(BinaryWriter w) {*
> > > > >
> > > > > *if (c)*
> > > > > *w.writeInt("A", a)*
> > > > > *else*
> > > > > *w.writeInt("B", b)*
> > > > >
> > > > > *w.writeBoolean("C", c);*
> > > > > *}*
> > > > >
> > > > > D.
> > > > >
> > > > > On Wed, Apr 12, 2017 at 1:07 AM, Vladimir Ozerov <
> > voze...@gridgain.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > Consider the following code:
> > > > > >
> > > > > > void writeBinary(BinaryWriter w) {
> > > > > > w.writeBoolean("C", c);
> > > > > >
> > > > > > if (c)
> > > > > > w.writeInt("A", a)
> > > > > > else
> > > > > > w.writeInt("B", b)
> > > > > > }
> > > > > >
> > > > > > How are we going to force user to follow the contract in this
> case?
> > > > > >
> > > > > > On Wed, Apr 12, 2017 at 9:16 AM, Dmitriy Setrakyan <
> > > > > dsetrak...@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > > I think it is OK for users to do their own sorting, but we
> should
> > > > > > > definitely validate the correct order and throw an exception if
> > it
> > > is
> > > > > > not.
> > > > > > >
> > > > > > > D.
> > > > > > >
> > > > > > > On Tue, Apr 11, 2017 at 11:02 PM, Pavel Tupitsyn <
> > > > ptupit...@apache.org
> > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > QueryEntity order is not only harder for the users, it will
> be
> > > > > > nightmare
> > > > > > > to
> > > > > > > > implement.
> > > > > > > > What if there is no QueryEntity defined? What if the same
> class
> > > is
> > > > > used
> > > > > > > in
> > > > > > > > multiple QueryEntity?
> > > > > > > > I don't think serialization code has to be tied to
> QueryEntity
> > in
> > > > any
> > > > > > > way,
> > > > > > > > this violates separation of concerns.
> > > > > > > >
> > > > > > > > So I guess we can agree on sorting fields alphabetically.
> > > > > > > >
> > > > > > > > Let's get to the initial question:
> > > > > > > > * Should we do the sorting for the user (performance hit)?
> > > > > > > > * Should we at least validate user-defined order?
> > > > > > > >
> > > > > > > > On Wed, Apr 12, 2017 at 2:12 AM, Dmitriy Setrakyan <
> > > > > > > dsetrak...@apache.org>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > On Tue, Apr 11, 2017 at 1:28 PM, Sergi Vladykin <
> > > > > > > > sergi.vlady...@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > I'm just trying to understand the current state of things
> > and
> > > > > > risks.
> > > > > > > > May
> > > > > > > > > be
> > > > > > > > > > we need to do some adjustments here before 2.0 to be on
> the
> > > > safe
> > > > > > > side.
> > > > > > > > > >
> > > > > > > > > > Actually looks like this not really important, we just
> have
> > > to
> > > > > > > clearly
> > > > > > > > > > document that DML builds keys this way and require from
> > user
> > > to
> > > > > do
> > > > > > > the
> > > > > > > > > same
> > > > > > > > > > to be able to use cache API.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > I think it is important from the usability stand point. A
> > user
> > > > can
> > > > > > > always
> > > > > > > > > sort fields alphabetically in his or her mind. However,
> > trying
> > > to
> > > > > > > > remember
> > > > > > > > > the field order from some QueryEntity is a lot harder.
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>


Re: TouchedExpiryPolicy works incorrect in some cases IGNITE-4401

2017-04-13 Thread ALEKSEY KUZNETSOV
any feedback?

чт, 13 апр. 2017 г. в 11:51, ALEKSEY KUZNETSOV :

> You should run ExpiryPolicyTest. The output should contain strings like
> contains? new AffinityKey("1", "1"): and contains?2 new AffinityKey("1", "
> 1"): and empty cursor? =
> If you look at them you will see, that cache contains affinity key new
> AffinityKey("1", "1") whereas cursor is empty(on second iteration). From
> this output you can conclude SQL query returns icorrect data(empty value)
>
>
> чт, 13 апр. 2017 г. в 3:42, Denis Magda :
>
>> Bluntly speaking I have no idea where to look and what to expect. This is
>> output of the test execution of my machine:
>>
>> SQL res: [[1], [d]]
>> 2
>> Op consume: 303
>> Value: org.ignite.test.EDU@22db8f4
>> SQL res: []
>> 0
>> Op consume: 9
>> Value: org.ignite.test.EDU@29caf222
>> SQL res: []
>> 0
>> Op consume: 15
>> Value: org.ignite.test.EDU@7cd1ac19
>> SQL res: []
>> 0
>> Op consume: 5
>>
>> Please be more specific, there are too many files in the code.
>>
>> —
>> Denis
>>
>> > On Apr 12, 2017, at 4:50 AM, ALEKSEY KUZNETSOV <
>> alkuznetsov...@gmail.com> wrote:
>> >
>> > So what do u think about the issue ?
>> >
>> > ср, 12 апр. 2017 г. в 10:42, ALEKSEY KUZNETSOV <
>> alkuznetsov...@gmail.com>:
>> >
>> >> I have already attached simlified version. Shall i simplify it more ?
>> >>
>> >> вт, 11 апр. 2017 г. в 19:28, Denis Magda :
>> >>
>> >> Can you attach the simplified version? Just want to avoid any side
>> effects.
>> >>
>> >> —
>> >> Denis
>> >>
>> >>> On Apr 11, 2017, at 9:14 AM, ALEKSEY KUZNETSOV <
>> alkuznetsov...@gmail.com>
>> >> wrote:
>> >>>
>> >>> I took it from https://issues.apache.org/jira/browse/IGNITE-4401 <
>> >> https://issues.apache.org/jira/browse/IGNITE-4401> and simplified .
>> See
>> >> in attached
>> >>>
>> >>>
>> >>> вт, 11 апр. 2017 г. в 19:03, Denis Magda  >> dma...@apache.org>>:
>> >>> Hello,
>> >>>
>> >>> Do you have sample code?
>> >>>
>> >>> —
>> >>> Denis
>>  On Apr 11, 2017, at 2:45 AM, ALEKSEY KUZNETSOV <
>> >> alkuznetsov...@gmail.com > wrote:
>> 
>>  Hi, igniters!
>>  While doing https://issues.apache.org/jira/browse/IGNITE-4401 <
>> >> https://issues.apache.org/jira/browse/IGNITE-4401> ticket i came
>>  across the fact that cache querying returns null , while cache still
>> >> has
>>  got entry.
>>  Cache query : SELECT nameProp FROM EDUProp WHERE EDUId = 1
>>  Cache get operation : ignite().cache("eduPropCache").get(new
>> >> AffinityKey("1",
>>  "1")) non-null
>>  I cannot even imagine what could be wrong with it.
>> 
>> 
>> 
>>  --
>> 
>>  *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: Sorting fields of Binarilyzable objects on write

2017-04-13 Thread Vladimir Ozerov
Folks,

If you restrict writes in certain order and conditions, Binarylizable
interfaces turns into an unusable bullshit :-) Remember that not all binary
objects participate in DML, and even if so, not all binary objects are
cache keys. I think we should simply print a warning to log, informing user
about potential problems if order is violated.

On Thu, Apr 13, 2017 at 2:16 PM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:

> That is cool, completely forgot about it :)
>
> 2017-04-13 14:07 GMT+03:00 Pavel Tupitsyn :
>
> > Alexey, we can read fields in any order in non-raw mode.
> > Dmitriy's suggestion would work.
> >
> > On Thu, Apr 13, 2017 at 1:56 PM, Alexey Goncharuk <
> > alexey.goncha...@gmail.com> wrote:
> >
> > > Dmitriy,
> > >
> > > How would then reader determine which field to read (a and b could the
> of
> > > different size)? c in this case must be written first.
> > >
> > > 2017-04-13 0:29 GMT+03:00 Dmitriy Setrakyan :
> > >
> > > > Vladimir,
> > > >
> > > > Would this be valid?
> > > >
> > > > *void writeBinary(BinaryWriter w) {*
> > > >
> > > > *if (c)*
> > > > *w.writeInt("A", a)*
> > > > *else*
> > > > *w.writeInt("B", b)*
> > > >
> > > > *w.writeBoolean("C", c);*
> > > > *}*
> > > >
> > > > D.
> > > >
> > > > On Wed, Apr 12, 2017 at 1:07 AM, Vladimir Ozerov <
> voze...@gridgain.com
> > >
> > > > wrote:
> > > >
> > > > > Consider the following code:
> > > > >
> > > > > void writeBinary(BinaryWriter w) {
> > > > > w.writeBoolean("C", c);
> > > > >
> > > > > if (c)
> > > > > w.writeInt("A", a)
> > > > > else
> > > > > w.writeInt("B", b)
> > > > > }
> > > > >
> > > > > How are we going to force user to follow the contract in this case?
> > > > >
> > > > > On Wed, Apr 12, 2017 at 9:16 AM, Dmitriy Setrakyan <
> > > > dsetrak...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > I think it is OK for users to do their own sorting, but we should
> > > > > > definitely validate the correct order and throw an exception if
> it
> > is
> > > > > not.
> > > > > >
> > > > > > D.
> > > > > >
> > > > > > On Tue, Apr 11, 2017 at 11:02 PM, Pavel Tupitsyn <
> > > ptupit...@apache.org
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > QueryEntity order is not only harder for the users, it will be
> > > > > nightmare
> > > > > > to
> > > > > > > implement.
> > > > > > > What if there is no QueryEntity defined? What if the same class
> > is
> > > > used
> > > > > > in
> > > > > > > multiple QueryEntity?
> > > > > > > I don't think serialization code has to be tied to QueryEntity
> in
> > > any
> > > > > > way,
> > > > > > > this violates separation of concerns.
> > > > > > >
> > > > > > > So I guess we can agree on sorting fields alphabetically.
> > > > > > >
> > > > > > > Let's get to the initial question:
> > > > > > > * Should we do the sorting for the user (performance hit)?
> > > > > > > * Should we at least validate user-defined order?
> > > > > > >
> > > > > > > On Wed, Apr 12, 2017 at 2:12 AM, Dmitriy Setrakyan <
> > > > > > dsetrak...@apache.org>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > On Tue, Apr 11, 2017 at 1:28 PM, Sergi Vladykin <
> > > > > > > sergi.vlady...@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > I'm just trying to understand the current state of things
> and
> > > > > risks.
> > > > > > > May
> > > > > > > > be
> > > > > > > > > we need to do some adjustments here before 2.0 to be on the
> > > safe
> > > > > > side.
> > > > > > > > >
> > > > > > > > > Actually looks like this not really important, we just have
> > to
> > > > > > clearly
> > > > > > > > > document that DML builds keys this way and require from
> user
> > to
> > > > do
> > > > > > the
> > > > > > > > same
> > > > > > > > > to be able to use cache API.
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > I think it is important from the usability stand point. A
> user
> > > can
> > > > > > always
> > > > > > > > sort fields alphabetically in his or her mind. However,
> trying
> > to
> > > > > > > remember
> > > > > > > > the field order from some QueryEntity is a lot harder.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>


Re: Sorting fields of Binarilyzable objects on write

2017-04-13 Thread Alexey Goncharuk
That is cool, completely forgot about it :)

2017-04-13 14:07 GMT+03:00 Pavel Tupitsyn :

> Alexey, we can read fields in any order in non-raw mode.
> Dmitriy's suggestion would work.
>
> On Thu, Apr 13, 2017 at 1:56 PM, Alexey Goncharuk <
> alexey.goncha...@gmail.com> wrote:
>
> > Dmitriy,
> >
> > How would then reader determine which field to read (a and b could the of
> > different size)? c in this case must be written first.
> >
> > 2017-04-13 0:29 GMT+03:00 Dmitriy Setrakyan :
> >
> > > Vladimir,
> > >
> > > Would this be valid?
> > >
> > > *void writeBinary(BinaryWriter w) {*
> > >
> > > *if (c)*
> > > *w.writeInt("A", a)*
> > > *else*
> > > *w.writeInt("B", b)*
> > >
> > > *w.writeBoolean("C", c);*
> > > *}*
> > >
> > > D.
> > >
> > > On Wed, Apr 12, 2017 at 1:07 AM, Vladimir Ozerov  >
> > > wrote:
> > >
> > > > Consider the following code:
> > > >
> > > > void writeBinary(BinaryWriter w) {
> > > > w.writeBoolean("C", c);
> > > >
> > > > if (c)
> > > > w.writeInt("A", a)
> > > > else
> > > > w.writeInt("B", b)
> > > > }
> > > >
> > > > How are we going to force user to follow the contract in this case?
> > > >
> > > > On Wed, Apr 12, 2017 at 9:16 AM, Dmitriy Setrakyan <
> > > dsetrak...@apache.org>
> > > > wrote:
> > > >
> > > > > I think it is OK for users to do their own sorting, but we should
> > > > > definitely validate the correct order and throw an exception if it
> is
> > > > not.
> > > > >
> > > > > D.
> > > > >
> > > > > On Tue, Apr 11, 2017 at 11:02 PM, Pavel Tupitsyn <
> > ptupit...@apache.org
> > > >
> > > > > wrote:
> > > > >
> > > > > > QueryEntity order is not only harder for the users, it will be
> > > > nightmare
> > > > > to
> > > > > > implement.
> > > > > > What if there is no QueryEntity defined? What if the same class
> is
> > > used
> > > > > in
> > > > > > multiple QueryEntity?
> > > > > > I don't think serialization code has to be tied to QueryEntity in
> > any
> > > > > way,
> > > > > > this violates separation of concerns.
> > > > > >
> > > > > > So I guess we can agree on sorting fields alphabetically.
> > > > > >
> > > > > > Let's get to the initial question:
> > > > > > * Should we do the sorting for the user (performance hit)?
> > > > > > * Should we at least validate user-defined order?
> > > > > >
> > > > > > On Wed, Apr 12, 2017 at 2:12 AM, Dmitriy Setrakyan <
> > > > > dsetrak...@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > > On Tue, Apr 11, 2017 at 1:28 PM, Sergi Vladykin <
> > > > > > sergi.vlady...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > I'm just trying to understand the current state of things and
> > > > risks.
> > > > > > May
> > > > > > > be
> > > > > > > > we need to do some adjustments here before 2.0 to be on the
> > safe
> > > > > side.
> > > > > > > >
> > > > > > > > Actually looks like this not really important, we just have
> to
> > > > > clearly
> > > > > > > > document that DML builds keys this way and require from user
> to
> > > do
> > > > > the
> > > > > > > same
> > > > > > > > to be able to use cache API.
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I think it is important from the usability stand point. A user
> > can
> > > > > always
> > > > > > > sort fields alphabetically in his or her mind. However, trying
> to
> > > > > > remember
> > > > > > > the field order from some QueryEntity is a lot harder.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>


Re: Sorting fields of Binarilyzable objects on write

2017-04-13 Thread Pavel Tupitsyn
Alexey, we can read fields in any order in non-raw mode.
Dmitriy's suggestion would work.

On Thu, Apr 13, 2017 at 1:56 PM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:

> Dmitriy,
>
> How would then reader determine which field to read (a and b could the of
> different size)? c in this case must be written first.
>
> 2017-04-13 0:29 GMT+03:00 Dmitriy Setrakyan :
>
> > Vladimir,
> >
> > Would this be valid?
> >
> > *void writeBinary(BinaryWriter w) {*
> >
> > *if (c)*
> > *w.writeInt("A", a)*
> > *else*
> > *w.writeInt("B", b)*
> >
> > *w.writeBoolean("C", c);*
> > *}*
> >
> > D.
> >
> > On Wed, Apr 12, 2017 at 1:07 AM, Vladimir Ozerov 
> > wrote:
> >
> > > Consider the following code:
> > >
> > > void writeBinary(BinaryWriter w) {
> > > w.writeBoolean("C", c);
> > >
> > > if (c)
> > > w.writeInt("A", a)
> > > else
> > > w.writeInt("B", b)
> > > }
> > >
> > > How are we going to force user to follow the contract in this case?
> > >
> > > On Wed, Apr 12, 2017 at 9:16 AM, Dmitriy Setrakyan <
> > dsetrak...@apache.org>
> > > wrote:
> > >
> > > > I think it is OK for users to do their own sorting, but we should
> > > > definitely validate the correct order and throw an exception if it is
> > > not.
> > > >
> > > > D.
> > > >
> > > > On Tue, Apr 11, 2017 at 11:02 PM, Pavel Tupitsyn <
> ptupit...@apache.org
> > >
> > > > wrote:
> > > >
> > > > > QueryEntity order is not only harder for the users, it will be
> > > nightmare
> > > > to
> > > > > implement.
> > > > > What if there is no QueryEntity defined? What if the same class is
> > used
> > > > in
> > > > > multiple QueryEntity?
> > > > > I don't think serialization code has to be tied to QueryEntity in
> any
> > > > way,
> > > > > this violates separation of concerns.
> > > > >
> > > > > So I guess we can agree on sorting fields alphabetically.
> > > > >
> > > > > Let's get to the initial question:
> > > > > * Should we do the sorting for the user (performance hit)?
> > > > > * Should we at least validate user-defined order?
> > > > >
> > > > > On Wed, Apr 12, 2017 at 2:12 AM, Dmitriy Setrakyan <
> > > > dsetrak...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > On Tue, Apr 11, 2017 at 1:28 PM, Sergi Vladykin <
> > > > > sergi.vlady...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > I'm just trying to understand the current state of things and
> > > risks.
> > > > > May
> > > > > > be
> > > > > > > we need to do some adjustments here before 2.0 to be on the
> safe
> > > > side.
> > > > > > >
> > > > > > > Actually looks like this not really important, we just have to
> > > > clearly
> > > > > > > document that DML builds keys this way and require from user to
> > do
> > > > the
> > > > > > same
> > > > > > > to be able to use cache API.
> > > > > > >
> > > > > >
> > > > > >
> > > > > > I think it is important from the usability stand point. A user
> can
> > > > always
> > > > > > sort fields alphabetically in his or her mind. However, trying to
> > > > > remember
> > > > > > the field order from some QueryEntity is a lot harder.
> > > > > >
> > > > >
> > > >
> > >
> >
>


Re: Sorting fields of Binarilyzable objects on write

2017-04-13 Thread Alexey Goncharuk
Dmitriy,

How would then reader determine which field to read (a and b could the of
different size)? c in this case must be written first.

2017-04-13 0:29 GMT+03:00 Dmitriy Setrakyan :

> Vladimir,
>
> Would this be valid?
>
> *void writeBinary(BinaryWriter w) {*
>
> *if (c)*
> *w.writeInt("A", a)*
> *else*
> *w.writeInt("B", b)*
>
> *w.writeBoolean("C", c);*
> *}*
>
> D.
>
> On Wed, Apr 12, 2017 at 1:07 AM, Vladimir Ozerov 
> wrote:
>
> > Consider the following code:
> >
> > void writeBinary(BinaryWriter w) {
> > w.writeBoolean("C", c);
> >
> > if (c)
> > w.writeInt("A", a)
> > else
> > w.writeInt("B", b)
> > }
> >
> > How are we going to force user to follow the contract in this case?
> >
> > On Wed, Apr 12, 2017 at 9:16 AM, Dmitriy Setrakyan <
> dsetrak...@apache.org>
> > wrote:
> >
> > > I think it is OK for users to do their own sorting, but we should
> > > definitely validate the correct order and throw an exception if it is
> > not.
> > >
> > > D.
> > >
> > > On Tue, Apr 11, 2017 at 11:02 PM, Pavel Tupitsyn  >
> > > wrote:
> > >
> > > > QueryEntity order is not only harder for the users, it will be
> > nightmare
> > > to
> > > > implement.
> > > > What if there is no QueryEntity defined? What if the same class is
> used
> > > in
> > > > multiple QueryEntity?
> > > > I don't think serialization code has to be tied to QueryEntity in any
> > > way,
> > > > this violates separation of concerns.
> > > >
> > > > So I guess we can agree on sorting fields alphabetically.
> > > >
> > > > Let's get to the initial question:
> > > > * Should we do the sorting for the user (performance hit)?
> > > > * Should we at least validate user-defined order?
> > > >
> > > > On Wed, Apr 12, 2017 at 2:12 AM, Dmitriy Setrakyan <
> > > dsetrak...@apache.org>
> > > > wrote:
> > > >
> > > > > On Tue, Apr 11, 2017 at 1:28 PM, Sergi Vladykin <
> > > > sergi.vlady...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > I'm just trying to understand the current state of things and
> > risks.
> > > > May
> > > > > be
> > > > > > we need to do some adjustments here before 2.0 to be on the safe
> > > side.
> > > > > >
> > > > > > Actually looks like this not really important, we just have to
> > > clearly
> > > > > > document that DML builds keys this way and require from user to
> do
> > > the
> > > > > same
> > > > > > to be able to use cache API.
> > > > > >
> > > > >
> > > > >
> > > > > I think it is important from the usability stand point. A user can
> > > always
> > > > > sort fields alphabetically in his or her mind. However, trying to
> > > > remember
> > > > > the field order from some QueryEntity is a lot harder.
> > > > >
> > > >
> > >
> >
>


Re: CREATE TABLE SQL command syntax

2017-04-13 Thread Sergi Vladykin
CREATE TABLE () WITH "cacheCfgUrl or templateName or anything you want"

Sergi

2017-04-13 12:43 GMT+03:00 Dmitriy Setrakyan :

> Sergi,
>
> I would avoid exposing the word "CACHE" on the SQL side. I prefer that we
> work with tables. I can see a use for a table_configuration(...) function
> to create configuration templates, but how would you associate a
> configuration template with a table inside of "create table" statement?
>
> D.
>
> On Wed, Apr 12, 2017 at 11:22 PM, Sergi Vladykin  >
> wrote:
>
> > I do not think we need it.
> >
> > In standard SQL we already have KEY and COLUMN, also we already have
> CREATE
> > TABLE syntax. Adding AFFINITY to them is not a big deal.
> >
> > The thing CONFIGURATION looks like a completely new entity for SQL and I
> > prefer to avoid sticking it into H2, also I would avoid having it in
> > Ignite.
> >
> > If we need to create cache configuration templates in SQL, then lets use
> > functions:
> >
> > CALL NEW_CACHE_CONFIGURATION(...);
> >
> > They will be completely independent from H2. The only problem is that (as
> > we already discussed time ago) that for better usability we may need to
> > contribute named parameters for H2 functions. But this is the right thing
> > to do here.
> >
> > Sergi
> >
> > 2017-04-12 23:59 GMT+03:00 Dmitriy Setrakyan :
> >
> > > Got it. Can we also add CONFIGURATION keyword?
> > >
> > > On Wed, Apr 12, 2017 at 11:34 AM, Sergi Vladykin <
> > sergi.vlady...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Dmitriy,
> > > >
> > > > H2 does not support any "user-specific" syntax and it should not.
> > Instead
> > > > it has a concept of Mode, which is basically a setting which allows
> H2
> > to
> > > > be compatible with other databases. For example, some keywords that
> > make
> > > > sense for other databases are just ignored, but this makes the
> > statement
> > > > from other BD work in H2.
> > > >
> > > > It allows us to introduce "ApacheIgnite" mode, which will allow to
> add
> > > some
> > > > minor tweaks into Parser. These tweaks will be covered by tests and
> no
> > > one
> > > > will be able to just silently break our code.
> > > >
> > > > Actually what I see is that we do not need any custom parsing at all,
> > all
> > > > we need is just need a couple of minor tweaks (like AFFINITY
> keyword),
> > > > other SQL must work as is. Thus trying to plug in a parser looks like
> > an
> > > > overkill and fragile idea a priori.
> > > >
> > > > Sergi
> > > >
> > > > 2017-04-12 20:40 GMT+03:00 Dmitriy Setrakyan  >:
> > > >
> > > > > Hm... I think the truth is somewhere in the middle here.
> > > > >
> > > > > The syntax proposed by Sergi makes sense to me. However, I am still
> > > > > struggling why would H2 accept our patch, if it has AFFINITY KEY
> > > keyword
> > > > in
> > > > > it, which has nothing to do with H2.
> > > > >
> > > > > It does sound like certain portions of SQL do need to be plugable
> to
> > > > > support the user-specific syntax.
> > > > >
> > > > > Sergi, am I missing something?
> > > > >
> > > > > D.
> > > > >
> > > > > On Wed, Apr 12, 2017 at 8:51 AM, Sergi Vladykin <
> > > > sergi.vlady...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > If it is that little, then all this copy/paste shit-coding makes
> no
> > > > > sense.
> > > > > >
> > > > > > We have to add a respective mode to H2, add respective tests to
> H2,
> > > so
> > > > > that
> > > > > > other contributors of H2 will not occasionally break our stuff.
> > Thats
> > > > it.
> > > > > >
> > > > > > I will be the first H2 committer who will reject you patch, don't
> > > waste
> > > > > > your time.
> > > > > >
> > > > > > Sergi
> > > > > >
> > > > > > 2017-04-12 16:33 GMT+03:00 Alexander Paschenko <
> > > > > > alexander.a.pasche...@gmail.com>:
> > > > > >
> > > > > > > Sergi,
> > > > > > >
> > > > > > > First, it would be as little as overriding the part responsible
> > for
> > > > > > > CREATE TABLE - there's no need to touch anything else as
> luckily
> > H2
> > > > > > > parser is internally structured well enough.
> > > > > > >
> > > > > > > Second, although it is not all-around perfect, I am most
> > confident
> > > > > > > that this is far better than dragging into H2 bunch of stuff
> that
> > > > they
> > > > > > > don't really need just because we need it there or can smug it
> > > there.
> > > > > > >
> > > > > > > I think I'll just spend some time in the weekend and come up
> > with a
> > > > > > > prototype as otherwise this talk seems to be just a chit-chat.
> > > > > > >
> > > > > > > - Alex
> > > > > > >
> > > > > > > 2017-04-12 14:38 GMT+03:00 Sergi Vladykin <
> > > sergi.vlady...@gmail.com
> > > > >:
> > > > > > > > So basically in inherited class you are going co copy/paste
> > base
> > > > > class
> > > > > > > > methods and tweak them? I don't like this approach.
> > > > > > > >
> > > > > > > > Sergi
> > > > > > > >
> > > > > > > > 

Re: CREATE TABLE SQL command syntax

2017-04-13 Thread Dmitriy Setrakyan
Sergi,

I would avoid exposing the word "CACHE" on the SQL side. I prefer that we
work with tables. I can see a use for a table_configuration(...) function
to create configuration templates, but how would you associate a
configuration template with a table inside of "create table" statement?

D.

On Wed, Apr 12, 2017 at 11:22 PM, Sergi Vladykin 
wrote:

> I do not think we need it.
>
> In standard SQL we already have KEY and COLUMN, also we already have CREATE
> TABLE syntax. Adding AFFINITY to them is not a big deal.
>
> The thing CONFIGURATION looks like a completely new entity for SQL and I
> prefer to avoid sticking it into H2, also I would avoid having it in
> Ignite.
>
> If we need to create cache configuration templates in SQL, then lets use
> functions:
>
> CALL NEW_CACHE_CONFIGURATION(...);
>
> They will be completely independent from H2. The only problem is that (as
> we already discussed time ago) that for better usability we may need to
> contribute named parameters for H2 functions. But this is the right thing
> to do here.
>
> Sergi
>
> 2017-04-12 23:59 GMT+03:00 Dmitriy Setrakyan :
>
> > Got it. Can we also add CONFIGURATION keyword?
> >
> > On Wed, Apr 12, 2017 at 11:34 AM, Sergi Vladykin <
> sergi.vlady...@gmail.com
> > >
> > wrote:
> >
> > > Dmitriy,
> > >
> > > H2 does not support any "user-specific" syntax and it should not.
> Instead
> > > it has a concept of Mode, which is basically a setting which allows H2
> to
> > > be compatible with other databases. For example, some keywords that
> make
> > > sense for other databases are just ignored, but this makes the
> statement
> > > from other BD work in H2.
> > >
> > > It allows us to introduce "ApacheIgnite" mode, which will allow to add
> > some
> > > minor tweaks into Parser. These tweaks will be covered by tests and no
> > one
> > > will be able to just silently break our code.
> > >
> > > Actually what I see is that we do not need any custom parsing at all,
> all
> > > we need is just need a couple of minor tweaks (like AFFINITY keyword),
> > > other SQL must work as is. Thus trying to plug in a parser looks like
> an
> > > overkill and fragile idea a priori.
> > >
> > > Sergi
> > >
> > > 2017-04-12 20:40 GMT+03:00 Dmitriy Setrakyan :
> > >
> > > > Hm... I think the truth is somewhere in the middle here.
> > > >
> > > > The syntax proposed by Sergi makes sense to me. However, I am still
> > > > struggling why would H2 accept our patch, if it has AFFINITY KEY
> > keyword
> > > in
> > > > it, which has nothing to do with H2.
> > > >
> > > > It does sound like certain portions of SQL do need to be plugable to
> > > > support the user-specific syntax.
> > > >
> > > > Sergi, am I missing something?
> > > >
> > > > D.
> > > >
> > > > On Wed, Apr 12, 2017 at 8:51 AM, Sergi Vladykin <
> > > sergi.vlady...@gmail.com>
> > > > wrote:
> > > >
> > > > > If it is that little, then all this copy/paste shit-coding makes no
> > > > sense.
> > > > >
> > > > > We have to add a respective mode to H2, add respective tests to H2,
> > so
> > > > that
> > > > > other contributors of H2 will not occasionally break our stuff.
> Thats
> > > it.
> > > > >
> > > > > I will be the first H2 committer who will reject you patch, don't
> > waste
> > > > > your time.
> > > > >
> > > > > Sergi
> > > > >
> > > > > 2017-04-12 16:33 GMT+03:00 Alexander Paschenko <
> > > > > alexander.a.pasche...@gmail.com>:
> > > > >
> > > > > > Sergi,
> > > > > >
> > > > > > First, it would be as little as overriding the part responsible
> for
> > > > > > CREATE TABLE - there's no need to touch anything else as luckily
> H2
> > > > > > parser is internally structured well enough.
> > > > > >
> > > > > > Second, although it is not all-around perfect, I am most
> confident
> > > > > > that this is far better than dragging into H2 bunch of stuff that
> > > they
> > > > > > don't really need just because we need it there or can smug it
> > there.
> > > > > >
> > > > > > I think I'll just spend some time in the weekend and come up
> with a
> > > > > > prototype as otherwise this talk seems to be just a chit-chat.
> > > > > >
> > > > > > - Alex
> > > > > >
> > > > > > 2017-04-12 14:38 GMT+03:00 Sergi Vladykin <
> > sergi.vlady...@gmail.com
> > > >:
> > > > > > > So basically in inherited class you are going co copy/paste
> base
> > > > class
> > > > > > > methods and tweak them? I don't like this approach.
> > > > > > >
> > > > > > > Sergi
> > > > > > >
> > > > > > > 2017-04-12 14:07 GMT+03:00 Alexander Paschenko <
> > > > > > > alexander.a.pasche...@gmail.com>:
> > > > > > >
> > > > > > >> Sergi,
> > > > > > >>
> > > > > > >> As I've written in my previous post, it would be just
> inheriting
> > > > > Parser
> > > > > > on
> > > > > > >> Ignite side and plugging its instance in SINGLE place. Just
> > making
> > > > > H2's
> > > > > > >> Parser internal methods protected instead of private would let
> > us
> > > do
> > > 

Re: CachePojoStore data loading with binary marshaller

2017-04-13 Thread Dmitriy Setrakyan
On Thu, Apr 13, 2017 at 12:16 AM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> It's not illegal in general, but it doesn't make sense for out of the box
> implementation of cache store.\
>

Ouch. I didn't realize that we deserialize in our own cache store. Any
reason for this behavior? Can this be fixed before the release?


[GitHub] ignite pull request #1786: IGNITE-3523 IGFS: Remove "initialize default path...

2017-04-13 Thread tledkov-gridgain
GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-3523  IGFS: Remove "initialize default path modes" feature



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

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

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

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


commit 9d5b6b27a4afcdebee9af56f4b16d06ac1058cc9
Author: tledkov-gridgain 
Date:   2017-04-12T15:17:14Z

IGNITE-3523 IGFS: Remove "initialize default path modes" feature

commit 5b8ec64dc99c9918cc245f00ae9fe9649ca21224
Author: tledkov-gridgain 
Date:   2017-04-13T07:57:08Z

Merge branch '_master' into ignite-3523




---
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 - 4760 ready for review

2017-04-13 Thread Вадим Опольский
Hi, guys!

Semyon, have you had a time to review IGNITE-4760
https://github.com/apache/ignite/pull/1768 ?

Is this fix actual for hibernate5 module?

Vadim Opolski

2017-04-11 13:40 GMT+03:00 Semyon Boikov :

> Thanks Vadim, I'll try to do review today.
>
> Semyon
>
> On Mon, Apr 10, 2017 at 8:15 PM, Вадим Опольский 
> wrote:
>
>> Hello guys!
>>
>> Semyon, review please again. Test check corresponding IgniteCaches
>> contain expected number of entries. Test fails for
>> HibernateNonStrictAccessStrategy.
>> And per-cache thread local in method threadLocalForCache fix this issue.
>>
>> https://github.com/apache/ignite/pull/1768/files
>>
>> Vadim Opolski
>>
>>
>> 2017-04-07 14:15 GMT+03:00 Semyon Boikov :
>>
>>> Hi Vadim,
>>>
>>> Test does not look correct to me. I think test need check that
>>> corresponding IgniteCaches contain expected number of entries like
>>> 'testCacheUsage' does.
>>>
>>> Thanks
>>>
>>> On Wed, Apr 5, 2017 at 3:26 PM, Вадим Опольский 
>>> wrote:
>>>
 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
 


 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/5aa25f3830fef14ac5
 07ed73872d62b2969a7411/modules/hibernate/src/main/java/org/a
 pache/ignite/cache/hibernate/HibernateRegionFactory.java

 https://github.com/vadopolski/ignite/blob/5aa25f3830fef14ac5
 07ed73872d62b2969a7411/modules/hibernate/src/test/java/org/a
 pache/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, Вадим Опольский <
> vaopols...@gmail.com >
> > wrote:
> >
> > > Hello everybody,
> > >
> > > I want to resolve issue №4760
> > > https://issues.apache.org/jira/browse/IGNITE-4760 <
> 

Re: TouchedExpiryPolicy works incorrect in some cases IGNITE-4401

2017-04-13 Thread ALEKSEY KUZNETSOV
You should run ExpiryPolicyTest. The output should contain strings like
contains? new AffinityKey("1", "1"): and contains?2 new AffinityKey("1", "1"
): and empty cursor? =
If you look at them you will see, that cache contains affinity key new
AffinityKey("1", "1") whereas cursor is empty(on second iteration). From
this output you can conclude SQL query returns icorrect data(empty value)


чт, 13 апр. 2017 г. в 3:42, Denis Magda :

> Bluntly speaking I have no idea where to look and what to expect. This is
> output of the test execution of my machine:
>
> SQL res: [[1], [d]]
> 2
> Op consume: 303
> Value: org.ignite.test.EDU@22db8f4
> SQL res: []
> 0
> Op consume: 9
> Value: org.ignite.test.EDU@29caf222
> SQL res: []
> 0
> Op consume: 15
> Value: org.ignite.test.EDU@7cd1ac19
> SQL res: []
> 0
> Op consume: 5
>
> Please be more specific, there are too many files in the code.
>
> —
> Denis
>
> > On Apr 12, 2017, at 4:50 AM, ALEKSEY KUZNETSOV 
> wrote:
> >
> > So what do u think about the issue ?
> >
> > ср, 12 апр. 2017 г. в 10:42, ALEKSEY KUZNETSOV  >:
> >
> >> I have already attached simlified version. Shall i simplify it more ?
> >>
> >> вт, 11 апр. 2017 г. в 19:28, Denis Magda :
> >>
> >> Can you attach the simplified version? Just want to avoid any side
> effects.
> >>
> >> —
> >> Denis
> >>
> >>> On Apr 11, 2017, at 9:14 AM, ALEKSEY KUZNETSOV <
> alkuznetsov...@gmail.com>
> >> wrote:
> >>>
> >>> I took it from https://issues.apache.org/jira/browse/IGNITE-4401 <
> >> https://issues.apache.org/jira/browse/IGNITE-4401> and simplified . See
> >> in attached
> >>>
> >>>
> >>> вт, 11 апр. 2017 г. в 19:03, Denis Magda > dma...@apache.org>>:
> >>> Hello,
> >>>
> >>> Do you have sample code?
> >>>
> >>> —
> >>> Denis
>  On Apr 11, 2017, at 2:45 AM, ALEKSEY KUZNETSOV <
> >> alkuznetsov...@gmail.com > wrote:
> 
>  Hi, igniters!
>  While doing https://issues.apache.org/jira/browse/IGNITE-4401 <
> >> https://issues.apache.org/jira/browse/IGNITE-4401> ticket i came
>  across the fact that cache querying returns null , while cache still
> >> has
>  got entry.
>  Cache query : SELECT nameProp FROM EDUProp WHERE EDUId = 1
>  Cache get operation : ignite().cache("eduPropCache").get(new
> >> AffinityKey("1",
>  "1")) non-null
>  I cannot even imagine what could be wrong with it.
> 
> 
> 
>  --
> 
>  *Best Regards,*
> 
>  *Kuznetsov Aleksey*
> >>>
> >>> --
> >>> Best Regards,
> >>>
> >>> Kuznetsov Aleksey
> >>>
> >>
> >> --
> >>
> >> *Best Regards,*
> >>
> >> *Kuznetsov Aleksey*
> >>
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
>
> --

*Best Regards,*

*Kuznetsov Aleksey*


[GitHub] ignite pull request #1785: IGNITE-4954 - Configurable expiration timeout for...

2017-04-13 Thread vkulichenko
GitHub user vkulichenko opened a pull request:

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

IGNITE-4954 - Configurable expiration timeout for Casssndra session



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

$ git pull https://github.com/vkulichenko/ignite ignite-4954

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

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


commit 4652877b0444eb72181982030082dce6e9b4dec1
Author: Valentin Kulichenko 
Date:   2017-04-13T08:29:30Z

IGNITE-4954 - Configurable expiration timeout for Casssndra session




---
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: build failure in the master branch

2017-04-13 Thread Vyacheslav Daradur
Rishi, thank you.

It is building well, with commits before 12.04.17

2017-04-12 15:37 GMT+03:00 Rishi Yagnik :

> I build it last night it worked for me..I am using Jdk8-121, hope that
> helps ..
>
> Take Care,
> Rishi
>
> > On Apr 12, 2017, at 5:37 AM, Vyacheslav Daradur 
> wrote:
> >
> > Does anyone has the same problem?
> >
> > 2017-04-12 12:30 GMT+03:00 Vyacheslav Daradur :
> >
> >> Last commit [1] 12.04.2017 6:19:06
> >>
> >> mvn -X clean package -DskipTests
> >>
> >> result:
> >> ***
> >> [DEBUG] parsing done in 2ms.
> >> JavaDoc error: 'Other Packages' section should not be present, all
> >> packages shou
> >> ld have corresponding documentation groups: C:\Users\SBT-Daradur-V\
> >> Projects\igni
> >> te\target\javadoc\core/overview-summary.html
> >> [DEBUG] parsing started
> >> [DEBUG] DomTree builder started.
> >> [DEBUG] LagartoDom tree created in 4 ms.
> >> [DEBUG] parsing done in 5ms.
> >> [DEBUG] parsing started
> >> [DEBUG] DomTree builder started.
> >> [DEBUG] LagartoDom tree created in 4 ms.
> >> [DEBUG] parsing done in 4ms.
> >> [INFO] 
> >> 
> >> [INFO] Reactor Summary:
> >> [INFO]
> >> [INFO] ignite-apache-license-gen .. SUCCESS [
> >> 1.473 s]
> >> [INFO] ignite-tools ... SUCCESS [
> >> 5.950 s]
> >> [INFO] ignite-core  SUCCESS
> >> [02:25 min]
> >> [INFO] ignite-log4j ... SUCCESS [
> >> 4.440 s]
> >> [INFO] ignite-indexing  SUCCESS [
> >> 12.198 s]
> >> [INFO] ignite-urideploy ... SUCCESS [
> >> 4.338 s]
> >> [INFO] ignite-spring .. SUCCESS [
> >> 5.500 s]
> >> [INFO] ignite-hadoop .. SUCCESS [
> >> 15.860 s]
> >> [INFO] ignite-extdata-p2p . SUCCESS [
> >> 4.629 s]
> >> [INFO] ignite-extdata-uri-dep . SUCCESS [
> >> 2.210 s]
> >> [INFO] ignite-extdata-uri . SUCCESS [
> >> 1.033 s]
> >> [INFO] ignite-rest-http ... SUCCESS [
> >> 4.003 s]
> >> [INFO] ignite-clients . SUCCESS [
> >> 2.153 s]
> >> [INFO] ignite-spring-data . SUCCESS [
> >> 3.284 s]
> >> [INFO] ignite-web . SUCCESS [
> >> 3.487 s]
> >> [INFO] ignite-aop . SUCCESS [
> >> 3.365 s]
> >> [INFO] ignite-ssh . SUCCESS [
> >> 3.135 s]
> >> [INFO] ignite-jta . SUCCESS [
> >> 3.762 s]
> >> [INFO] ignite-aws . SUCCESS [
> >> 3.550 s]
> >> [INFO] ignite-log4j2 .. SUCCESS [
> >> 3.074 s]
> >> [INFO] ignite-slf4j ... SUCCESS [
> >> 2.650 s]
> >> [INFO] ignite-jcl . SUCCESS [
> >> 2.515 s]
> >> [INFO] ignite-codegen . SUCCESS [
> >> 2.364 s]
> >> [INFO] ignite-gce . SUCCESS [
> >> 2.713 s]
> >> [INFO] ignite-cloud ... SUCCESS [
> >> 4.806 s]
> >> [INFO] ignite-mesos ... SUCCESS [
> >> 4.260 s]
> >> [INFO] ignite-kafka ... SUCCESS [
> >> 4.889 s]
> >> [INFO] ignite-flume ... SUCCESS [
> >> 3.584 s]
> >> [INFO] ignite-yarn  SUCCESS [
> >> 10.306 s]
> >> [INFO] ignite-jms11 ... SUCCESS [
> >> 3.234 s]
> >> [INFO] ignite-twitter . SUCCESS [
> >> 3.141 s]
> >> [INFO] ignite-mqtt  SUCCESS [
> >> 3.578 s]
> >> [INFO] ignite-zookeeper ... SUCCESS [
> >> 3.395 s]
> >> [INFO] ignite-camel ... SUCCESS [
> >> 3.579 s]
> >> [INFO] ignite-storm ... SUCCESS [
> >> 3.147 s]
> >> [INFO] ignite-osgi-paxlogging . SUCCESS [
> >> 0.728 s]
> >> [INFO] ignite-osgi-karaf .. SUCCESS [
> >> 0.381 s]
> >> [INFO] ignite-osgi  SUCCESS [
> >> 4.074 s]
> >> [INFO] ignite-appserver-test .. SUCCESS [
> >> 0.591 s]
> >> [INFO] ignite-websphere-test .. SUCCESS [
> >> 3.345 s]
> >> [INFO] ignite-cassandra ... SUCCESS [
> >> 0.355 s]
> >> [INFO] ignite-cassandra-store . SUCCESS [
> >> 10.290 s]
> 

[GitHub] ignite pull request #1784: Ignite 4927

2017-04-13 Thread abeliak
GitHub user abeliak opened a pull request:

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

Ignite 4927



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

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

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

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


commit b8cb82de65a529040ea18b0dc03fa7109c69bb4a
Author: Vasiliy Sisko 
Date:   2016-12-29T07:48:45Z

IGNITE-4442 Implemented cache affinity configuration.

(cherry picked from commit f4a1e6c)

commit 852f03829c997883376245e3515e47822e9012eb
Author: Andrey Novikov 
Date:   2017-01-11T09:34:23Z

Merge branches 'ignite-1.7.5' and 'web-console-production' of 
https://github.com/gridgain/apache-ignite into web-console-production

commit d3e2e0c5574f7677645e73e1fbafaee3563895f1
Author: Andrey Novikov 
Date:   2017-01-25T07:27:01Z

Merge branches 'ignite-1.7.6' and 'web-console-production' of 
https://github.com/gridgain/apache-ignite into web-console-production

commit 295f80d10da02692540435d46961a9c3cca99b3c
Author: Andrey Novikov 
Date:   2017-01-25T06:58:57Z

IGNITE-4520 Added credential request for authentication on proxy.

(cherry picked from commit ef04f35)

commit faa20530a707014ac34477cba8adaaa4b67de1bb
Author: Andrey Novikov 
Date:   2017-01-25T09:48:05Z

IGNITE-1596 Fixed version sort.

(cherry picked from commit 128ba07)

commit 1b3bbdb1758eb19c755dabcb5fe329529fa0f378
Author: Andrey Novikov 
Date:   2017-01-27T04:30:49Z

IGNITE-4622 Fixed generation in domain model for cache store.

(cherry picked from commit 43007d5)

commit a8355feef630a5c8c4edbe02224c8325dd5952d3
Author: Andrey Novikov 
Date:   2017-02-03T04:58:43Z

IGNITE-4610 Added more informative message.

(cherry picked from commit 9ff2a8f)

commit 94d8a6fc0a61bb3046e2ebd8b3cbffb8917c2b6a
Author: Andrey Novikov 
Date:   2017-02-08T04:43:22Z

IGNITE-4472 Added user activities in Web Console.

(cherry picked from commit 26ee9c2)

commit b571fd40f009709718bce0c969d47b62be06b8f6
Author: Andrey Novikov 
Date:   2017-02-08T10:05:08Z

IGNITE-4472 Added user activities in Web Console.

(cherry picked from commit 26ee9c2)

commit db48f545a83bb72cded77d8269fe4f8820e8380f
Author: Andrey Novikov 
Date:   2017-02-10T08:55:05Z

IGNITE-4678 Web Console: Implemented demo load as service.

(cherry picked from commit a600caf)

commit e4b54c985f256478ae2cae23b423d9b8e0842df8
Author: Andrey Novikov 
Date:   2017-02-13T02:48:50Z

Merge branch 'ignite-1.8.3' of https://github.com/gridgain/apache-ignite 
into web-console-production

commit 2d6735a20ac8009d1ac3f003da4fcd319271bd71
Author: Alexey Kuznetsov 
Date:   2017-02-09T09:44:41Z

IGNITE-4676 Fixed hang if closure executed nested internal task with 
continuation. Added test.

(cherry picked from commit e7a5307)

commit d307e2eced1fd10b007ee08c3dd113e7bb4f22ba
Author: Andrey Novikov 
Date:   2017-02-13T10:35:29Z

IGNITE-4687 Added pool to process REST request in Web Agent.

(cherry picked from commit 262a341)

commit 8874f99f44dc2edf08a525619edb49d5db70b938
Author: dkarachentsev 
Date:   2017-02-14T15:44:57Z

IGNITE-4641 - Refresh client attributes during reconnect

commit ca5956bedfc0c3bd18290c64b6a6c2e3f114a440
Author: Andrey Novikov 
Date:   2017-02-14T16:28:06Z

IGNITE-4472 UI fix, minor fixes

(cherry picked from commit 79e1e53)

commit db9252c9588c671279664484bb8c397312d265e6
Author: Andrey Novikov 
Date:   2017-02-15T09:08:57Z

IGNITE-4678 Node version in range.

(cherry picked from commit 2cfd55d)

commit 58c0c49d31605bf4608e7ee97099b75b324a782f
Author: Andrey Novikov 
Date:   2017-02-16T03:41:30Z

IGNITE-4472 Fixed became this user.

(cherry picked from commit ee832e4)

commit 2ccbf32ea3ecaff1068832accf37235a32734b4b
Author: Andrey Novikov 
Date:   2017-02-16T07:22:22Z

IGNITE-4472 Minor UI fix.

(cherry picked from commit 97c7ed7)

commit ef4886d5be7c708b917e97b1cd5fd766b2ad8450
Author: Andrey Novikov 
Date:   2017-02-16T11:38:40Z

IGNITE-4472 Minor UI fix.

(cherry picked from commit d4efbf3)

commit 05788b3188b30b5a3b39a75fe66301e03658408f
Author: Andrey V. Mashenkov 
Date:   2017-02-17T09:14:53Z

IGNITE-3429: Added 

Re: question: How data are stored in IgniteCache?

2017-04-13 Thread Vyacheslav Daradur
Denis, thank you for answers.

I meant another.

For example:
Cache queries use a BinaryObjectImpl and a withKeepBinary-mode use it, so
looks like all actions on serialized object are make via a BinaryObjectImpl.

Does a serialized object always is stored as BinaryObjectImpl or it will be
wrapped on demand?

2017-04-12 22:34 GMT+03:00 Denis Magda :

> A Java wrapper around an actual binary byte array with some additional
> fields and methods to work with the serialized data.
>
> —
> Denis
>
> > On Apr 12, 2017, at 8:33 AM, Vyacheslav Daradur 
> wrote:
> >
> > In what cases BinaryObjecImpl is used?
> >
> > 2017-04-12 18:08 GMT+03:00 Denis Magda :
> >
> >> Hi,
> >>
> >> A cache entry is always stored in a binary format (byte array) in a
> cache.
> >> Even when you transfer an entry from one node to another, as a result of
> >> cache.put(…), operation the entry will be serialized into the binary
> format
> >> and transferred over the wire.
> >>
> >> —
> >> Denis
> >>
> >>> On Apr 12, 2017, at 1:11 AM, Vyacheslav Daradur 
> >> wrote:
> >>>
> >>> Hello Igniters!
> >>>
> >>> I have one conceptual question:
> >>>
> >>> When we put an object in IgniteCache, how it is stored?
> >>>
> >>> As I understand, after marshalling we have an array of bytes,
> >>> 1) in a local node it is wrapped in BinaryObjectImpl and stored in
> memory
> >>> 2) it is sent to remote node as byte array where it will be wrapped in
> >>> BinaryObjectImpl and be stored in memory
> >>>
> >>> --
> >>> Best Regards, Vyacheslav
> >>
> >>
> >
> >
> > --
> > Best Regards, Vyacheslav
>
>


-- 
Best Regards, Vyacheslav


Re: IGNITE-2741 - spring session design

2017-04-13 Thread Valentin Kulichenko
Rishi,

Can you tell exact steps to reproduce? It's working for me in my
environment.

Do I understand correctly that apart from the token issue, it works fine
with new version?

-Val

On Wed, Apr 12, 2017 at 10:00 PM, Rishi Yagnik 
wrote:

> Val,
>
> I build it from master s and was able to integrate with our app, but as I
> mentioned to you previously, I see the XSRF-Token errors in debug log,
>
> [DEBUG] [XNIO-2 task-4] org.springframework.security.web.FilterChainProxy
> -
> /app/xxx/yyy/zz/A at position 3 of 13 in additional filter chain; firing
> Filter: 'HeaderWriterFilter'
> [DEBUG] [XNIO-2 task-4] org.springframework.security.web.FilterChainProxy
> -
> /app/xxx/yyy/zz/A at position 4 of 13 in additional filter chain; firing
> Filter: 'CsrfFilter'
>
> [DEBUG] [XNIO-2 task-4] org.springframework.security.web.csrf.CsrfFilter -
> Invalid CSRF token found for http://localhost:9002/app/xxx/yyy/zz/A
>
> And, then after, CSRF filter does not like the session, redirects to /403
> error.
>
> Just wondering why the XSRF Token is not being saved in the session  ?
>
> More debugging is require for sure..
>
> of course there is a work around to the problem, I can just use Cookie
> based Token repository to avoid this issue.
>
> .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse())
>
>
> will let you know my findings..
>
> As always, thanks for all your help.
>
> Thanks,
> Rishi
>
>
> On Tue, Apr 11, 2017 at 4:18 PM, Rishi Yagnik 
> wrote:
>
> > Hi Val,
> >
> > I will build it from master s and let you know by tomorrow.
> >
> > Thanks,
> >
> >
> > On Tue, Apr 11, 2017 at 3:53 PM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> >> Hi Rishi,
> >>
> >> What was the issue with the HttpSessionCsrfTokenRepository? I didn't
> have
> >> any problems after I added code you provided.
> >>
> >> The fix for [1] is already in master. Can you try building from there
> and
> >> check if everything works fine for you?
> >>
> >> [1] https://issues.apache.org/jira/browse/IGNITE-4948
> >>
> >> -Val
> >>
> >> On Sat, Mar 18, 2017 at 5:15 PM, Denis Magda 
> wrote:
> >>
> >> > Somewhere in April. This will be clarified on the dev list soon.
> >> >
> >> > On Saturday, March 18, 2017, Rishi Yagnik 
> >> wrote:
> >> >
> >> > > Thanks, Val.
> >> > >
> >> > > When are we going to release Ignite 2.0 ? June ??
> >> > >
> >> > > Thanks,
> >> > >
> >> > > On Sat, Mar 18, 2017 at 6:02 AM, Valentin Kulichenko <
> >> > > valentin.kuliche...@gmail.com > wrote:
> >> > >
> >> > > > Denis,
> >> > > >
> >> > > > Yes, this should be possible. I will try to finalize the fix asap.
> >> > > >
> >> > > > -Val
> >> > > >
> >> > > > On Fri, Mar 17, 2017 at 7:46 PM, Denis Magda  >> > > > wrote:
> >> > > >
> >> > > > > Val,
> >> > > > >
> >> > > > > Will it be possible to incorporate the fix into the nearest 2.0
> >> > > release?
> >> > > > >
> >> > > > > —
> >> > > > > Denis
> >> > > > >
> >> > > > > > On Mar 17, 2017, at 11:43 AM, Rishi Yagnik <
> >> rishiyag...@gmail.com
> >> > > >
> >> > > > > wrote:
> >> > > > > >
> >> > > > > > Hi Val,
> >> > > > > >
> >> > > > > > Hope you are well, any update on web session clustering.
> >> > > > > >
> >> > > > > > Thanks,
> >> > > > > > Rishi
> >> > > > > >
> >> > > > > > On Sat, Mar 11, 2017 at 12:29 PM, Rishi Yagnik <
> >> > > rishiyag...@gmail.com >
> >> > > > > > wrote:
> >> > > > > >
> >> > > > > >> Hi Val,
> >> > > > > >>
> >> > > > > >> Thanks looking forward for the fix..
> >> > > > > >>
> >> > > > > >> Take Care,
> >> > > > > >> Rishi
> >> > > > > >>
> >> > > > > >>> On Mar 11, 2017, at 11:31 AM, Valentin Kulichenko <
> >> > > > > >> valentin.kuliche...@gmail.com > wrote:
> >> > > > > >>>
> >> > > > > >>> Hi Rishi,
> >> > > > > >>>
> >> > > > > >>> I want to fix the bug first. It takes a bit longer than I
> >> > thought,
> >> > > > but
> >> > > > > I
> >> > > > > >>> should finish it over the weekend.
> >> > > > > >>>
> >> > > > > >>> -Val
> >> > > > > >>>
> >> > > > >  On Fri, Mar 10, 2017 at 4:13 AM, Rishi Yagnik <
> >> > > > rishiyag...@gmail.com >
> >> > > > > >> wrote:
> >> > > > > 
> >> > > > >  Hi Val,
> >> > > > > 
> >> > > > >  Did you chance to look into session handling issue ?
> >> > > > > 
> >> > > > >  Thanks,
> >> > > > > 
> >> > > > >  On Mon, Mar 6, 2017 at 3:37 PM, Rishi Yagnik <
> >> > > rishiyag...@gmail.com 
> >> > > > >
> >> > > > >  wrote:
> >> > > > > 
> >> > > > > > Hi Val,
> >> > > > > >
> >> > > > > > Do you think I can test a fix in 1.9 RC releases ? How are
> >> you
> >> > > > > planning
> >> > > > >  to
> >> > > > > > release a fix ?
> >> > > > > >
> >> > > > > > Did you also look into problem where storing xsrf token in
> >> > Ignite
> >> > > > > >> returns
> >> > > > 

Re: CachePojoStore data loading with binary marshaller

2017-04-13 Thread Valentin Kulichenko
It's not illegal in general, but it doesn't make sense for out of the box
implementation of cache store.

-Val

On Wed, Apr 12, 2017 at 11:27 PM, Dmitriy Setrakyan 
wrote:

> On Wed, Apr 12, 2017 at 12:24 AM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Hi Dmitry,
> >
> > I can't advise a lot on implementation details, but generally I don't
> think
> > that CacheJdbcPojoStore should ever work with POJO classes in case binary
> > marshaller is enabled. It should always work directly with binary objects
> > even if POJOs are on server classpath, and switch to POJOs only when
> other
> > marshaller is used.
> >
> > Makes sense?
> >
>
> Valentin, this makes sense from the performance stand point. However, why
> should it be illegal to deserialize a binary object into class, if the
> class it on the classpath?
>


[jira] [Created] (IGNITE-4955) Correctly execute SQL queries started on replicated cache.

2017-04-13 Thread Sergi Vladykin (JIRA)
Sergi Vladykin created IGNITE-4955:
--

 Summary: Correctly execute SQL queries started on replicated cache.
 Key: IGNITE-4955
 URL: https://issues.apache.org/jira/browse/IGNITE-4955
 Project: Ignite
  Issue Type: Improvement
Reporter: Sergi Vladykin
Assignee: Sergi Vladykin
Priority: Blocker
 Fix For: 2.0






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


Re: CREATE TABLE SQL command syntax

2017-04-13 Thread Sergi Vladykin
I do not think we need it.

In standard SQL we already have KEY and COLUMN, also we already have CREATE
TABLE syntax. Adding AFFINITY to them is not a big deal.

The thing CONFIGURATION looks like a completely new entity for SQL and I
prefer to avoid sticking it into H2, also I would avoid having it in Ignite.

If we need to create cache configuration templates in SQL, then lets use
functions:

CALL NEW_CACHE_CONFIGURATION(...);

They will be completely independent from H2. The only problem is that (as
we already discussed time ago) that for better usability we may need to
contribute named parameters for H2 functions. But this is the right thing
to do here.

Sergi

2017-04-12 23:59 GMT+03:00 Dmitriy Setrakyan :

> Got it. Can we also add CONFIGURATION keyword?
>
> On Wed, Apr 12, 2017 at 11:34 AM, Sergi Vladykin  >
> wrote:
>
> > Dmitriy,
> >
> > H2 does not support any "user-specific" syntax and it should not. Instead
> > it has a concept of Mode, which is basically a setting which allows H2 to
> > be compatible with other databases. For example, some keywords that make
> > sense for other databases are just ignored, but this makes the statement
> > from other BD work in H2.
> >
> > It allows us to introduce "ApacheIgnite" mode, which will allow to add
> some
> > minor tweaks into Parser. These tweaks will be covered by tests and no
> one
> > will be able to just silently break our code.
> >
> > Actually what I see is that we do not need any custom parsing at all, all
> > we need is just need a couple of minor tweaks (like AFFINITY keyword),
> > other SQL must work as is. Thus trying to plug in a parser looks like an
> > overkill and fragile idea a priori.
> >
> > Sergi
> >
> > 2017-04-12 20:40 GMT+03:00 Dmitriy Setrakyan :
> >
> > > Hm... I think the truth is somewhere in the middle here.
> > >
> > > The syntax proposed by Sergi makes sense to me. However, I am still
> > > struggling why would H2 accept our patch, if it has AFFINITY KEY
> keyword
> > in
> > > it, which has nothing to do with H2.
> > >
> > > It does sound like certain portions of SQL do need to be plugable to
> > > support the user-specific syntax.
> > >
> > > Sergi, am I missing something?
> > >
> > > D.
> > >
> > > On Wed, Apr 12, 2017 at 8:51 AM, Sergi Vladykin <
> > sergi.vlady...@gmail.com>
> > > wrote:
> > >
> > > > If it is that little, then all this copy/paste shit-coding makes no
> > > sense.
> > > >
> > > > We have to add a respective mode to H2, add respective tests to H2,
> so
> > > that
> > > > other contributors of H2 will not occasionally break our stuff. Thats
> > it.
> > > >
> > > > I will be the first H2 committer who will reject you patch, don't
> waste
> > > > your time.
> > > >
> > > > Sergi
> > > >
> > > > 2017-04-12 16:33 GMT+03:00 Alexander Paschenko <
> > > > alexander.a.pasche...@gmail.com>:
> > > >
> > > > > Sergi,
> > > > >
> > > > > First, it would be as little as overriding the part responsible for
> > > > > CREATE TABLE - there's no need to touch anything else as luckily H2
> > > > > parser is internally structured well enough.
> > > > >
> > > > > Second, although it is not all-around perfect, I am most confident
> > > > > that this is far better than dragging into H2 bunch of stuff that
> > they
> > > > > don't really need just because we need it there or can smug it
> there.
> > > > >
> > > > > I think I'll just spend some time in the weekend and come up with a
> > > > > prototype as otherwise this talk seems to be just a chit-chat.
> > > > >
> > > > > - Alex
> > > > >
> > > > > 2017-04-12 14:38 GMT+03:00 Sergi Vladykin <
> sergi.vlady...@gmail.com
> > >:
> > > > > > So basically in inherited class you are going co copy/paste base
> > > class
> > > > > > methods and tweak them? I don't like this approach.
> > > > > >
> > > > > > Sergi
> > > > > >
> > > > > > 2017-04-12 14:07 GMT+03:00 Alexander Paschenko <
> > > > > > alexander.a.pasche...@gmail.com>:
> > > > > >
> > > > > >> Sergi,
> > > > > >>
> > > > > >> As I've written in my previous post, it would be just inheriting
> > > > Parser
> > > > > on
> > > > > >> Ignite side and plugging its instance in SINGLE place. Just
> making
> > > > H2's
> > > > > >> Parser internal methods protected instead of private would let
> us
> > do
> > > > the
> > > > > >> trick.
> > > > > >>
> > > > > >> — Alex
> > > > > >>
> > > > > >> среда, 12 апреля 2017 г. пользователь Sergi Vladykin написал:
> > > > > >>
> > > > > >> > I don't see how you make H2 Parser extendable, you will have
> to
> > > add
> > > > > >> plugin
> > > > > >> > call to every *potentially* extendable place in it. In general
> > > this
> > > > > does
> > > > > >> > not work. As H2 guy I would also reject patch like this.
> > > > > >> >
> > > > > >> > Sergi
> > > > > >> >
> > > > > >> > 2017-04-12 13:10 GMT+03:00 Alexander Paschenko <
> > > > > >> > alexander.a.pasche...@gmail.com >:
> > > > > >> >
> > > > > >> > > 

Re: Session expiration in Cassandra store

2017-04-13 Thread Igor Rudyak
Hi Val,

Keeping session forever is not good cause it consumes resources on server
and client side as well. On the client for example you have bunch of Netty
threads.

I think if you just specify session expiration timeout to some big value (1
day for example) it should be far enough.

Igor

On Wed, Apr 12, 2017 at 12:01 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Igor,
>
> Thanks! I'm a bit in a rush with this, so already created a ticket [1] and
> assigned it to myself if you don't mind :)
>
> One more question though. Why exactly keeping sessions "forever" is bad? I
> expect store operations to happen while node is up, and currently if there
> is a pause larger than 5 minutes between consequent operations, I have to
> reopen connection which causes slowdown. I'm not sure what is the benefit
> of this and what are we trying to solve with this. Can you please clarify?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-4954
>
> -Val
>
> On Wed, Apr 12, 2017 at 5:47 PM, Igor Rudyak  wrote:
>
>> Hi Val,
>>
>> 1) The genral idea is to have a session pool, cause closing and reopening
>> Cassandra session each time is rather expensive operation.
>>
>> 2) I can easily add session expiration timeout as a parameter for
>> Cassandra store. Will create a ticket for this.
>>
>> 3) It could be easily implemented ether, by closing and reopening session
>> every time or just keeping opened sessions forever, but both approaches are
>> bad. It's better to have a session pool and specify rather long session
>> expiration timeout.
>>
>> Igor
>>
>>
>>
>> On Apr 12, 2017 2:48 AM, "Valentin Kulichenko" <
>> valentin.kuliche...@gmail.com> wrote:
>>
>> Hi Igor,
>>
>> I recently faced an issue with Cassandra store closing idle connections
>> after some time. While investigating I found that this is caused by
>> SessionPool and its SessionMonitor thread which closes sessions that were
>> not acquired from the pool within 5 minutes.
>>
>> I have several questions regarding this:
>>
>>- What is the general idea behind this?
>>- Why the timeout is not configurable?
>>- Is it possible to add an option to disable this thread completely?
>>Will this have any drawbacks?
>>
>> -Val
>>
>>
>>
>


Re: Question about cache and transaction on different nodes

2017-04-13 Thread Sergi Vladykin
Yes, sorry. The test works correctly: tx started on grid0 does not affect
cache1, because they are on different nodes. Thus the operation
cache1.put(1, ) is successfully committed.

Still I would not recommend to rely on any of observed behaviors here,
because Ignite was not designed for mixing caches and transactions from
different nodes in the same code. This behavior is undefined, untested and
may freely change at any time.

Sergi

2017-04-13 0:08 GMT+03:00 Dmitriy Setrakyan :

> There is no bug.
>
> Dmitriy, you should introduce a variable:
>
> *cache0 = grid(0).cache(null);*
>
> Then you should use cache0 variable to do a cache put.
>
> You cannot use transaction API from grid0 and then cache API from grid1. In
> a normal environment, the cache0 and cache1 variables would not even be
> present in the same JVM - they would be on different physical servers.
>
> D.
>
> On Wed, Apr 12, 2017 at 11:08 AM, Sergi Vladykin  >
> wrote:
>
> > Looks like a bug to me.
> >
> > Sergi
> >
> > 2017-04-12 21:03 GMT+03:00 Дмитрий Рябов :
> >
> > > Why not? I do something with cache inside transaction. The only reason
> to
> > > not rollback is another node?
> > >
> > > 2017-04-12 19:52 GMT+03:00 Andrey Mashenkov <
> andrey.mashen...@gmail.com
> > >:
> > >
> > > > Hi Dmitry,
> > > >
> > > > Looks like you start transaction on node "grid(0)", but update value
> on
> > > > another node "grid(1)".
> > > > So, technically, it is not nested transactions, right?
> > > >
> > > > On Wed, Apr 12, 2017 at 7:32 PM, Дмитрий Рябов <
> somefire...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hello, igniters. I start the node and create a transactional cache
> on
> > > it,
> > > > > on the other node I start the transaction and "put" in previously
> > > created
> > > > > cache and rollback transaction. So what should I get? Value stored
> > > before
> > > > > transaction or inside rolled transaction?
> > > > >
> > > > > public void testRollback() throws Exception {
> > > > > startGrid(0);
> > > > > startGrid(1);
> > > > > IgniteCache cache1 = grid( 1).cache(null);
> > > > > cache1.put(1, 1);
> > > > > try (Transaction tx = grid(0).transactions().
> > txStart(PESSIMISTIC,
> > > > READ_COMMITTED)) {
> > > > > cache1.put(1, );
> > > > > tx.rollback();
> > > > > }
> > > > > assertEquals((Integer) 1, cache1.get(1));
> > > > > }
> > > > >
> > > > >
> > > > > The question is why I got  instead of 1? If it is right
> > behaviour -
> > > > > why it nowhere explained?
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > > Andrey V. Mashenkov
> > > >
> > >
> >
>