Re: [VOTE] Apache Ignite 1.9.0 RC1

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

+1

2017-03-01 10:28 GMT+03:00 Anton Vinogradov :

> Dear Sirs!
>
> We have uploaded the 1.9.0 release candidate to
> https://dist.apache.org/repos/dist/dev/ignite/1.9.0-rc1/
>
> Git tag name is
> 1.9.0-rc1
>
> This release includes the following changes:
>
> Ignite:
> * Added Data streamer mode for DML
> * Added Discovery SPI Implementation for Ignite Kubernetes Pods
> * SQL: Query can utilize multiple threads
> * SQL: Improved distributed SQL support
> * Benchmarking simplified and automated
> * Fixed licenses generation during build
> * ignite-spark module upgraded to Spark 2.0
>
> Ignite.NET:
> * DML support
> * TransactionScope API for Ignite transactions support
>
> Ignite CPP:
> * DML support
> * Implemented LoadCache
> * ContinuousQuery support
>
> Complete list of closed issues:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%
> 20fixVersion%20%3D%201.9%20AND%20(status%20%3D%
> 20closed%20or%20status%20%3D%20resolved)
>
> DEVNOTES
> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> plain;f=DEVNOTES.txt;hb=refs/tags/1.9.0-rc1
>
> RELEASENOTES
> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> plain;f=RELEASE_NOTES.txt;hb=refs/tags/1.9.0-rc1
>
> Please start voting.
>
> +1 - to accept Apache Ignite 1.9.0-rc1
> 0 - don't care either way
> -1 - DO NOT accept Apache Ignite 1.9.0-rc1 (explain why)
>
> This vote will go for 72 hours.
>



-- 
С уважением,
Чураев Антон

Re: IGNITE-4758 - introducing cache memory policies

[Sergey Chugunov]

Dmitriy,

Correct, cache configuration may contain a name of memory policy to use for
this cache.
If memory policy is not specified, a default one is used.

Thanks,
Sergey.

On Wed, Mar 1, 2017 at 1:02 AM, Dmitriy Setrakyan 
wrote:

> Thanks Sergey!
>
> Just to confirm, the same memory policy could be shared between different
> caches, right?
>
> D.
>
> On Tue, Feb 28, 2017 at 1:28 AM, Sergey Chugunov <
> sergey.chugu...@gmail.com>
> wrote:
>
> > Hello Ignite devs,
> >
> > I created new subtask  >
> > under IGNITE-3477 
> with
> > my vision of how *MemoryPolicy* may be implemented.
> >
> > In a nutshell my idea is as follows: instead of having only one instance
> of
> > *PageMemory* and managing a mapping [cacheId->pageMemory region] I
> suggest
> > introducing separate *PageMemory* instance (and corresponding *FreeList*
> > and *ReuseList* structures) for each *MemoryPolicy* configuration.
> > This instance will be stored in individual cache contexts instead of
> shared
> > cache context as it is right now.
> >
> > I think this design is a very natural extension of *PageMemory* concept
> and
> > should not introduce any performance degradation as no changes are
> > introduced into *PageMemory* implementation itself.
> >
> > Please share any thoughts or concerns about suggested design in this
> thread
> > or in comments under the subtask
> > .
> >
> > Thanks,
> > Sergey.
> >
>

[VOTE] Apache Ignite 1.9.0 RC1

[Anton Vinogradov]

Dear Sirs!

We have uploaded the 1.9.0 release candidate to
https://dist.apache.org/repos/dist/dev/ignite/1.9.0-rc1/

Git tag name is
1.9.0-rc1

This release includes the following changes:

Ignite:
* Added Data streamer mode for DML
* Added Discovery SPI Implementation for Ignite Kubernetes Pods
* SQL: Query can utilize multiple threads
* SQL: Improved distributed SQL support
* Benchmarking simplified and automated
* Fixed licenses generation during build
* ignite-spark module upgraded to Spark 2.0

Ignite.NET:
* DML support
* TransactionScope API for Ignite transactions support

Ignite CPP:
* DML support
* Implemented LoadCache
* ContinuousQuery support

Complete list of closed issues:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%201.9%20AND%20(status%20%3D%20closed%20or%20status%20%3D%20resolved)

DEVNOTES
https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=refs/tags/1.9.0-rc1

RELEASENOTES
https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=refs/tags/1.9.0-rc1

Please start voting.

+1 - to accept Apache Ignite 1.9.0-rc1
0 - don't care either way
-1 - DO NOT accept Apache Ignite 1.9.0-rc1 (explain why)

This vote will go for 72 hours.

[jira] [Created] (IGNITE-4763) Implement doSetRollbackOnly method to be implemented in SpringTransactionManager

[Sumanta Ghosh (JIRA)]

Sumanta Ghosh created IGNITE-4763:
-

 Summary: Implement doSetRollbackOnly method to be implemented in 
SpringTransactionManager
 Key: IGNITE-4763
 URL: https://issues.apache.org/jira/browse/IGNITE-4763
 Project: Ignite
  Issue Type: Bug
  Components: ignite-spring
Affects Versions: 1.8
Reporter: Sumanta Ghosh


This issue is raised in continuation with the message posted in ignite user 
forum 
(http://apache-ignite-users.70518.x6.nabble.com/SpringTransactionManager-Participating-in-existing-transactions-is-not-supported-td7305.html#a10624).
 Since the doSetRollBackOnly method is not implemented in 
SpringTransactionManager, it is not being possible to integrate with spring 
data's ChainedTransactionManager class. A simple fix (below) would work it 
seems (however, I did not yet tested with proper rollback test cases though, 
this implementation at least get rid of the exception chainedtransaction 
manager raises)

@Override 
protected void doSetRollbackOnly(DefaultTransactionStatus status) 
throws TransactionException { 
Transaction txn = 
((Ignite)this.getResourceFactory()).transactions().tx(); 
if (txn!=null) txn.setRollbackOnly(); 
}
NOTE: This is the first time I am raising issues in apache. So, apologies if 
all the details are not proper.



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

[jira] [Created] (IGNITE-4762) Support transactional updates in JDBC driver

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-4762:
---

 Summary: Support transactional updates in JDBC driver
 Key: IGNITE-4762
 URL: https://issues.apache.org/jira/browse/IGNITE-4762
 Project: Ignite
  Issue Type: Improvement
  Components: jdbc-driver, SQL
Affects Versions: 1.8
Reporter: Valentin Kulichenko


Currently transactions are not supported by SQL and therefore by JDBC driver.

However, it seems to be possible to provide support for multiple updates in a 
single transaction. We can add a special flag to JDBC driver to allow this.

Any SELECT queries will still be executed out of transactional scope.



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

Re: Remove CacheAtomicWriteOrderMode.CLOCK mode.

[Andrey Gura]

No, it should be removed. If somebody use entry last update time (e.g.
for conflict resolving) they should store this time as entry field.

On Wed, Mar 1, 2017 at 12:57 AM, Dmitriy Setrakyan
 wrote:
> Do we still need GridClockSyncProcessor?
>
> On Tue, Feb 28, 2017 at 5:26 AM, Andrey Gura  wrote:
>
>> Maxim,
>>
>> Yes, this setting doesn't make sense anymore. So we need remove all
>> related methods.
>>
>> Also there is component called GridClockSyncProcessor that also should
>> be removed. It will lead to removing globalTime field from
>> GridCacheVersion class and some related methods.
>>
>> On Tue, Feb 28, 2017 at 3:21 PM, Kozlov Maxim 
>> wrote:
>> > Valentin,
>> >
>> > Then there is no need for setting CacheConfiguration.atomicWriteOrderMode.
>> What do you think, remove it and and related methods?
>> >
>> >> 28 февр. 2017 г., в 2:49, Valentin Kulichenko <
>> valentin.kuliche...@gmail.com> написал(а):
>> >>
>> >> Hi Max,
>> >>
>> >> In case we remove the CLOCK mode, I think we should remove the enum
>> too, as
>> >> well as configuration properties and other code using this enum. Having
>> >> enum with one value doesn't make sense to me.
>> >>
>> >> -Val
>> >>
>> >> On Mon, Feb 27, 2017 at 5:09 AM, Kozlov Maxim 
>> wrote:
>> >>
>> >>> Hi Igniters,
>> >>>
>> >>> After remove CLOCK mode, CacheAtomicWriteOrderMode enum contains now
>> only
>> >>> one value PRIMARY. Andrey Gura, proposition remove
>> >>> CacheAtomicWriteOrderMode enum. Will there be something special for
>> this
>> >>> purpose is enum?
>> >>>
>> >>> jira: https://issues.apache.org/jira/browse/IGNITE-4587 <
>> >>> https://issues.apache.org/jira/browse/IGNITE-4587>
>> >>>
>> >>> --
>> >>> Best Regards,
>> >>> Max K.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >
>> > --
>> > Best Regards,
>> > Max K.
>> >
>> >
>> >
>> >
>>

Re: IGNITE-4758 - introducing cache memory policies

[Dmitriy Setrakyan]

Thanks Sergey!

Just to confirm, the same memory policy could be shared between different
caches, right?

D.

On Tue, Feb 28, 2017 at 1:28 AM, Sergey Chugunov 
wrote:

> Hello Ignite devs,
>
> I created new subtask 
> under IGNITE-3477  with
> my vision of how *MemoryPolicy* may be implemented.
>
> In a nutshell my idea is as follows: instead of having only one instance of
> *PageMemory* and managing a mapping [cacheId->pageMemory region] I suggest
> introducing separate *PageMemory* instance (and corresponding *FreeList*
> and *ReuseList* structures) for each *MemoryPolicy* configuration.
> This instance will be stored in individual cache contexts instead of shared
> cache context as it is right now.
>
> I think this design is a very natural extension of *PageMemory* concept and
> should not introduce any performance degradation as no changes are
> introduced into *PageMemory* implementation itself.
>
> Please share any thoughts or concerns about suggested design in this thread
> or in comments under the subtask
> .
>
> Thanks,
> Sergey.
>

Re: Remove CacheAtomicWriteOrderMode.CLOCK mode.

[Dmitriy Setrakyan]

Do we still need GridClockSyncProcessor?

On Tue, Feb 28, 2017 at 5:26 AM, Andrey Gura  wrote:

> Maxim,
>
> Yes, this setting doesn't make sense anymore. So we need remove all
> related methods.
>
> Also there is component called GridClockSyncProcessor that also should
> be removed. It will lead to removing globalTime field from
> GridCacheVersion class and some related methods.
>
> On Tue, Feb 28, 2017 at 3:21 PM, Kozlov Maxim 
> wrote:
> > Valentin,
> >
> > Then there is no need for setting CacheConfiguration.atomicWriteOrderMode.
> What do you think, remove it and and related methods?
> >
> >> 28 февр. 2017 г., в 2:49, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> написал(а):
> >>
> >> Hi Max,
> >>
> >> In case we remove the CLOCK mode, I think we should remove the enum
> too, as
> >> well as configuration properties and other code using this enum. Having
> >> enum with one value doesn't make sense to me.
> >>
> >> -Val
> >>
> >> On Mon, Feb 27, 2017 at 5:09 AM, Kozlov Maxim 
> wrote:
> >>
> >>> Hi Igniters,
> >>>
> >>> After remove CLOCK mode, CacheAtomicWriteOrderMode enum contains now
> only
> >>> one value PRIMARY. Andrey Gura, proposition remove
> >>> CacheAtomicWriteOrderMode enum. Will there be something special for
> this
> >>> purpose is enum?
> >>>
> >>> jira: https://issues.apache.org/jira/browse/IGNITE-4587 <
> >>> https://issues.apache.org/jira/browse/IGNITE-4587>
> >>>
> >>> --
> >>> Best Regards,
> >>> Max K.
> >>>
> >>>
> >>>
> >>>
> >>>
> >
> > --
> > Best Regards,
> > Max K.
> >
> >
> >
> >
>

Documenting Apache Ignite 1.9 Features

[Denis Magda]

Igniters,

We’ve already documented most of the features and improvements except the ones 
below.

Vovan, Igor, Alexander P., please spare some time this week preparing the docs. 
Once you’re done Prachi and I will do a final review. All the docs have to be 
ready by the time AI 1.9 gets released officially.
 
1) Parallel Query Execution (*Vovan*). Please add a section to “Distributed 
Queries” page:
https://issues.apache.org/jira/browse/IGNITE-4106

2) Data Streamer Mode DML (*Alexander P.*). Please add a section to 
“Distributed DML” page:
https://issues.apache.org/jira/browse/IGNITE-4169

3) C++ LoadCache (*Igor*). You can use Java cache store and loading approaches 
pages as a template:
https://issues.apache.org/jira/browse/IGNITE-4670

4) C++ DML and SQL Grid documentation (*Igor*). Please do the same way as Pavel 
did for .NET:
https://issues.apache.org/jira/browse/IGNITE-4620

This page might be useful if you don’t remember how we document a new feature 
that is missing in current release:
https://cwiki.apache.org/confluence/display/IGNITE/Documentation

—
Denis

Re: Hibernate OGM for Ignite. I need a help with documentation

[Denis Magda]

Hi Victor,

Looks like your contribution was accepted and will be rolled out as a part of 
the next release:
https://github.com/hibernate/hibernate-ogm/labels/Next%20release 


Is it so? Do you know when is the release scheduled for?

—
Denis

> On Jan 17, 2017, at 7:21 PM, Denis Magda  wrote:
> 
> CC-ing Victor.
> 
> Victor, please subscribe to the dev list so that you can get notifications 
> and participate in this discussion from your favorite mail agent.
> 
> —
> Denis
> 
>> On Jan 17, 2017, at 1:07 PM, Denis Magda  wrote:
>> 
>> Hi Vector,
>> 
>> This is amazing integration, you rock! You should have let Apache Ignite 
>> community about this before. Sure, we will be happy to assist you with the 
>> documentation from our side.
>> 
>> Could you a tiny code snippets to “Transactions” and “Queries” paragraphs 
>> just to show how to execute transactions or Ignite SQL queries from 
>> Hibernate OGM side?
>> 
>> *Prachi*, please review and edit Victor’s doc. 
>> 
>> [1]  
>> https://docs.google.com/document/d/1ZSFt9NPnN8EyOpNnNguc5-9FIDr4RfQLfAZMH0VgBPc/edit
>>  
>> 
>> 
>> —
>> Denis
>> 
>>> On Jan 17, 2017, at 12:18 PM, vikad111  wrote:
>>> 
>>> Hi everybody!
>>> 
>>> Hibernate OGM  is a JPA implementation for NoSQL
>>> datastores. I'm creating module for Apache Ignite.
>>> Here is my work
>>> , and 
>>> pull
>>> request  to Hibernate
>>> OGM
>>> I've almost done, but there is one issue with documentation. I have to
>>> write it.
>>> But I'm programmer, not a techwriter, and my English is not very good.
>>> I made a draft of documentation https://drive.google.com/open?id=0B2da3AGK_
>>> cO6TWpvVzFrWWF0dEk
>>> 
>>> Could you please take a look at this to correct mistakes or to add some
>>> useful information?
>>> 
>>> Here is existing documentation
>>>  that I
>>> used as an example.
>>> 
>>> Thank you in advance,
>>> Victor
>>> 
>>> 
>>> 
>>> 
>>> --
>>> View this message in context: 
>>> http://apache-ignite-developers.2346864.n4.nabble.com/Hibernate-OGM-for-Ignite-I-need-a-help-with-documentation-tp13762.html
>>> Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
>> 
> 

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

[Dani Traphagen]

I had this thought when exploring this parameter at first and only was able
to change my understanding when evaluating it more deeply in the source and
reaching out to other users/devs.

There could be an issue with new users who think increasing the hb
frequency will impact inter-node failure detection - so people might tweak
it thinking it does something it doesn't. I think renaming it could help
avoid this. This is because other systems use heartbeat frequencies for
failure detection protocols under the hood so people may be coming with
this understanding and think that's what this parameter is for.
On Tue, Feb 28, 2017 at 9:16 AM Denis Magda  wrote:

> They expect exactly what the name of the
> TcpDiscoverySpi.heartbeatsFrequency method says - rate of heartbeats will
> be adjusted if you play with this parameter.
>
> However, this is not true because the frequency of heartbeats is
> calculated from the failure detection timeout.
>
> —
> Denis
>
> > On Feb 28, 2017, at 7:28 AM, Yakov Zhdanov  wrote:
> >
> > Denis, I did not get your last message. What did users expect from
> changing
> > hbFreq?
> >
> > --Yakov
> >
> > 2017-02-28 4:08 GMT+03:00 Dmitriy Setrakyan :
> >
> >> Yakov, what do you think?
> >>
> >> On Mon, Feb 27, 2017 at 4:17 PM, Denis Magda  wrote:
> >>
> >>> Frankly, I decided to initiate this discussion after talking to many
> >>> Apache Ignite users who had initially thought that TcpDiscoverySpi.
> >> heartbeatsFrequency
> >>> manages the heartbeats and they had tried to tweak it not getting a
> >> desired
> >>> outcome. Even more, TcpDiscoverySpi.heartbeatsFrequenc’s javadoc
> already
> >>> states that this is for metrics frequency only but looks like the guys
> >>> hadn’t note this.
> >>>
> >>> So, personally, yes I would break the compatibility here which is fine
> to
> >>> do in 2.0.
> >>>
> >>> —
> >>> Denis
> >>>
>  On Feb 27, 2017, at 3:59 PM, Dmitriy Setrakyan  >
> >>> wrote:
> 
>  To me it sounds rather as an aesthetic change. Is it really worth
> >>> breaking
>  the API for this?
> 
>  On Mon, Feb 27, 2017 at 3:30 PM, Denis Magda 
> >> wrote:
> 
> > The heartbeats frequency has to be lower than the failure detection
> > timeout. This is why we decided to calculate the former basing on a
> >>> value
> > set for the latter rather than making a user to adjust both
> properties
> > properly. This is how both parameters became related some time ago :)
> >
> > Honestly, I don’t think that the javadoc improvement will make things
> > clearer for the users. Hope you will agree that people pay attention
> >> to
> >>> the
> > naming first and, only if the naming makes sense to them, learn more
> >>> about
> > the details referring to the javadoc.
> >
> > —
> > Denis
> >
> >> On Feb 27, 2017, at 2:59 PM, Dmitriy Setrakyan <
> >> dsetrak...@apache.org>
> > wrote:
> >>
> >> Hm... I don't think that heartbeat frequency has to be associated
> >> with
> >> failure detection. What if we just update the javadoc for this
> >>> parameter,
> >> stating that it has to do with metrics update only?
> >>
> >> On Mon, Feb 27, 2017 at 11:44 AM, Denis Magda 
> >>> wrote:
> >>
> >>> Igniters,
> >>>
> >>> Long time ago we updated the logic in discovery SPI that issues
> > heartbeats
> >>> messages from one node to another. Presently, heartbeats frequency
> >> is
> >>> calculated basing on IgniteConfiguration.failureDetectionTimeout
> > meaning
> >>> that TcpDiscoverySpi.heartbeatsFrequency has nothing to do with
> >>> heartbeats frequency at all.
> >>>
> >>> TcpDiscoverySpi.heartbeatsFrequency defines a frequency for metrics
> >>> message. So, I propose to rename this method in Apache Igntie 2.0
> to
> >>> something more meaningful like TcpDiscoverySpi.
> >>> metricsUpdateFrequency?
> >>>
> >>> Do you agree? Alternatives thoughts?
> >>>
> >>> —
> >>> Denis
> >
> >
> >>>
> >>>
> >>
>
>

Re: IGNITE-2741 - spring session design

[Rishi Yagnik]

Hi Val,

Sorry for pestering, thanks for all your help.

Rishi

On Mon, Feb 27, 2017 at 7:22 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Hi Rishi,
>
> Sorry, not yet. But this on my short list of TODOs, will try to give an
> update as soon as possible.
>
> -Val
>
> On Mon, Feb 27, 2017 at 7:47 AM, Rishi Yagnik 
> wrote:
>
> > Hi Val,
> >
> > any update on session replication issue ?
> >
> > Thanks,
> > Rishi
> >
> > On Thu, Feb 23, 2017 at 8:07 AM, Rishi Yagnik 
> > wrote:
> >
> > > Thanks Val for looking into it.
> > >
> > > On Wed, Feb 22, 2017 at 9:32 PM, Valentin Kulichenko <
> > > valentin.kuliche...@gmail.com> wrote:
> > >
> > >> Hi Rishi,
> > >>
> > >> Got it, I think I'm reproducing the issue. I'll take a look and let
> you
> > >> know my findings soon.
> > >>
> > >> -Val
> > >>
> > >> On Tue, Feb 21, 2017 at 7:27 PM, Rishi Yagnik 
> > >> wrote:
> > >>
> > >> > Hi Val,
> > >> >
> > >> > The issue will occur in cluster environment, please setup the spring
> > >> boot
> > >> > on 2 different host with LB (F5 OR Reverse proxy) in front and try
> to
> > >> > login.
> > >> >
> > >> > In cluster environment, Spring security does not recognize the
> session
> > >> on
> > >> > the host you are not logged in, as a result, spring security will
> > >> redirect
> > >> > to login url however the correct behavior should be that user would
> > stay
> > >> > logged in with session replication.
> > >> >
> > >> > Do let me know if you need more information.
> > >> >
> > >> > Thanks,
> > >> > Rishi
> > >> >
> > >> >
> > >> >
> > >> > On Tue, Feb 21, 2017 at 7:08 PM, Valentin Kulichenko <
> > >> > valentin.kuliche...@gmail.com> wrote:
> > >> >
> > >> > > Hi Rishi,
> > >> > >
> > >> > > I was able to build and run the application. Can you give some
> > >> > description
> > >> > > on what should I test to understand the issue? What exactly didn't
> > >> work
> > >> > for
> > >> > > you?
> > >> > >
> > >> > > -Val
> > >> > >
> > >> > > On Wed, Feb 15, 2017 at 10:52 AM, Valentin Kulichenko <
> > >> > > valentin.kuliche...@gmail.com> wrote:
> > >> > >
> > >> > > > Hi Rishi,
> > >> > > >
> > >> > > > Thanks, I'll take a look.
> > >> > > >
> > >> > > > -Val
> > >> > > >
> > >> > > > On Wed, Feb 15, 2017 at 9:07 AM, Rishi Yagnik <
> > >> rishiyag...@gmail.com>
> > >> > > > wrote:
> > >> > > >
> > >> > > >> Hi Val,
> > >> > > >>
> > >> > > >> As promised, please find attached code for spring boot
> > integration
> > >> > with
> > >> > > >> spring security along with Ignite.
> > >> > > >>
> > >> > > >> Some more information on project -
> > >> > > >>
> > >> > > >>- It is a maven project ( Ignite 1.7.0, SB 1.4.3 )
> > >> > > >>- spring security integrated with boot project along with
> > ignite
> > >> > > >>- HttpSessionCookieCsrfTokenRepository does not work, gives
> > >> > > >>intermediate errors on single instance so used
> > >> > > CookieCsrfTokenRepository
> > >> > > >>for CSRF token, again I think we need a fix here from
> Ignite.
> > >> > > >>
> > >> > > >> I cant reproduce this errors while I am running on single
> > instance,
> > >> > you
> > >> > > >> need to run this app on 2 spring boot instance having proxy in
> > >> front (
> > >> > > F5,
> > >> > > >> OR any proxy ) with round robin fashion ( no sticky session on
> F5
> > >> OR
> > >> > > >> proxies ).
> > >> > > >>
> > >> > > >> We were thinking with round robin the user session will active
> > >> since
> > >> > we
> > >> > > >> used session replication on backend.
> > >> > > >>
> > >> > > >> Do let me know if you need more information here.
> > >> > > >>
> > >> > > >> Thanks,
> > >> > > >>
> > >> > > >> Rishi
> > >> > > >>
> > >> > > >>
> > >> > > >>
> > >> > > >>
> > >> > > >> On Tue, Feb 14, 2017 at 9:57 PM, Rishi Yagnik <
> > >> rishiyag...@gmail.com>
> > >> > > >> wrote:
> > >> > > >>
> > >> > > >>> Val,
> > >> > > >>>
> > >> > > >>> My SB sample project is ready however I have asked for an
> > >> approval to
> > >> > > >>> submit sample project to you, it would take day or two.
> > >> > > >>>
> > >> > > >>> I will keep you posted.
> > >> > > >>>
> > >> > > >>> Thanks for all your help,
> > >> > > >>>
> > >> > > >>> On Tue, Feb 14, 2017 at 3:51 PM, Rishi Yagnik <
> > >> rishiyag...@gmail.com
> > >> > >
> > >> > > >>> wrote:
> > >> > > >>>
> > >> > >  Let me build an example app for you and send it across to
> you.
> > >> > > 
> > >> > >  Thanks,
> > >> > > 
> > >> > >  On Tue, Feb 14, 2017 at 3:28 PM, Valentin Kulichenko <
> > >> > >  valentin.kuliche...@gmail.com> wrote:
> > >> > > 
> > >> > > > Rishi,
> > >> > > >
> > >> > > > No I don't, and I think that's what we should start with. I
> > >> want to
> > >> > > > understand a use case that is currently not supported (if
> any)
> > >> and
> > >> > > then
> > >> > > > find the best solution. And I would like to reuse existing
> > code
> > >> as
> > 

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

[Denis Magda]

They expect exactly what the name of the TcpDiscoverySpi.heartbeatsFrequency 
method says - rate of heartbeats will be adjusted if you play with this 
parameter. 

However, this is not true because the frequency of heartbeats is calculated 
from the failure detection timeout.

—
Denis

> On Feb 28, 2017, at 7:28 AM, Yakov Zhdanov  wrote:
> 
> Denis, I did not get your last message. What did users expect from changing
> hbFreq?
> 
> --Yakov
> 
> 2017-02-28 4:08 GMT+03:00 Dmitriy Setrakyan :
> 
>> Yakov, what do you think?
>> 
>> On Mon, Feb 27, 2017 at 4:17 PM, Denis Magda  wrote:
>> 
>>> Frankly, I decided to initiate this discussion after talking to many
>>> Apache Ignite users who had initially thought that TcpDiscoverySpi.
>> heartbeatsFrequency
>>> manages the heartbeats and they had tried to tweak it not getting a
>> desired
>>> outcome. Even more, TcpDiscoverySpi.heartbeatsFrequenc’s javadoc already
>>> states that this is for metrics frequency only but looks like the guys
>>> hadn’t note this.
>>> 
>>> So, personally, yes I would break the compatibility here which is fine to
>>> do in 2.0.
>>> 
>>> —
>>> Denis
>>> 
 On Feb 27, 2017, at 3:59 PM, Dmitriy Setrakyan 
>>> wrote:
 
 To me it sounds rather as an aesthetic change. Is it really worth
>>> breaking
 the API for this?
 
 On Mon, Feb 27, 2017 at 3:30 PM, Denis Magda 
>> wrote:
 
> The heartbeats frequency has to be lower than the failure detection
> timeout. This is why we decided to calculate the former basing on a
>>> value
> set for the latter rather than making a user to adjust both properties
> properly. This is how both parameters became related some time ago :)
> 
> Honestly, I don’t think that the javadoc improvement will make things
> clearer for the users. Hope you will agree that people pay attention
>> to
>>> the
> naming first and, only if the naming makes sense to them, learn more
>>> about
> the details referring to the javadoc.
> 
> —
> Denis
> 
>> On Feb 27, 2017, at 2:59 PM, Dmitriy Setrakyan <
>> dsetrak...@apache.org>
> wrote:
>> 
>> Hm... I don't think that heartbeat frequency has to be associated
>> with
>> failure detection. What if we just update the javadoc for this
>>> parameter,
>> stating that it has to do with metrics update only?
>> 
>> On Mon, Feb 27, 2017 at 11:44 AM, Denis Magda 
>>> wrote:
>> 
>>> Igniters,
>>> 
>>> Long time ago we updated the logic in discovery SPI that issues
> heartbeats
>>> messages from one node to another. Presently, heartbeats frequency
>> is
>>> calculated basing on IgniteConfiguration.failureDetectionTimeout
> meaning
>>> that TcpDiscoverySpi.heartbeatsFrequency has nothing to do with
>>> heartbeats frequency at all.
>>> 
>>> TcpDiscoverySpi.heartbeatsFrequency defines a frequency for metrics
>>> message. So, I propose to rename this method in Apache Igntie 2.0 to
>>> something more meaningful like TcpDiscoverySpi.
>>> metricsUpdateFrequency?
>>> 
>>> Do you agree? Alternatives thoughts?
>>> 
>>> —
>>> Denis
> 
> 
>>> 
>>> 
>> 

[jira] [Created] (IGNITE-4761) ServiceProcessor hangs while stopping on unstable topology.

[Andrew Mashenkov (JIRA)]

Andrew Mashenkov created IGNITE-4761:


 Summary: ServiceProcessor hangs while stopping on unstable 
topology.
 Key: IGNITE-4761
 URL: https://issues.apache.org/jira/browse/IGNITE-4761
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.7
Reporter: Andrew Mashenkov
 Fix For: 2.0


GridServiceProcessor.onKernalStop can be blocked on taking busyLock when
the lock is being held by TopologyListener while infinite waiting for 
readyAffinityFuture.





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

Re: IGNITE-4713 : refactoring of GridFinishedFuture and GridFutureAdapter

[Yakov Zhdanov]

Alexander,

Can you please clarify this?

>I suppose "volatile" is not need here, because right now if 
>GridFutureAdapter#onDone()
called in another thread than GridFutureAdapter#get0, it will produce
AssertionError.

1) 99.999% of time GridFutureAdapter#onDone() is called in some other
thread than the one which is frozen on get()
2) What is volatile now which should not be?

Regarding the flag - boolean and byte takes 1 byte in the object. I suppose
some time ago there were 3 options, but now there are only 2. I don't think
we need to change it now.



--Yakov

2017-02-28 17:32 GMT+03:00 Александр Меньшиков :

> Sorry, I mean I want to do fast work on this issue (not make code faster).
> Your code is strange. You can see my view in my local temp PR:
>
> https://github.com/SharplEr/ignite/pull/4/files
>
> This is what I'm meaning.
>
> I suppose "volatile" is not need here, because right now if
> GridFutureAdapter#onDone() called in another thread than
> GridFutureAdapter#get0, it will produce AssertionError.
>
>
>
> 2017-02-28 16:57 GMT+03:00 Vladislav Pyatkov :
>
> > Alexander,
> >
> > Are you sure, which it will be faster?
> > The condition
> >
> > resFlag == RES and resFlag == ERR
> >
> > should be more complicated... like something this:
> >
> > getState() != 0 &&  !resFlag and getState() != 0 &&  resFlag
> >
> > But unlike getState(), restFag is not volatile...
> >
> > On Tue, Feb 28, 2017 at 4:26 PM, Александр Меньшиков <
> sharple...@gmail.com
> > > wrote:
> >
> >> Alexey, Vladislav, are you agree with me, or not? I want to do it faster
> >> and move on.
> >>
> >> 2017-02-17 17:36 GMT+03:00 Александр Меньшиков :
> >>
> >>> We can check "onDone" method was called with using getState() method.
> If
> >>> getState()!=0 then  resFlag!=0. Just look at code.
> >>>
> >>>
> >>> 2017-02-17 17:12 GMT+03:00 Александр Меньшиков :
> >>>
>  Like I said, if "resFlag==0" (of course 0 came from initialization)
>  means "you still haven't called the method onDone()", better make it
> clear.
> 
> 
> 
>  2017-02-17 14:48 GMT+03:00 Vladislav Pyatkov :
> 
> > Alexander,
> >
> > I think, the resFlag will be initiated as 0 (new
> GridFutureAdapter()),
> > but
> > 1 and 2 states will be acquired on live.
> >
> >
> > On Fri, Feb 17, 2017 at 1:56 PM, Александр Меньшиков <
> > sharple...@gmail.com>
> > wrote:
> >
> > > Alexey,
> > >
> > > I see only one place where writes in resFlag:
> > >
> > > if (err != null) {
> > > resFlag = ERR;
> > > this.res = err;
> > > }
> > > else {
> > > resFlag = RES;
> > > this.res = res;
> > > }
> > >
> > > And the comparison with only two values: "ERR" and "RES". Except
> > "assert
> > > resFlag != 0;". So if this "assert" protect from call "get0" before
> > call
> > > "onDone" I think will be clearer to set some ready flag or use
> > "enum" type.
> > > And throw IllegalStateException if condition is false, because
> right
> > now
> > > developer will not get clear error massage.
> > >
> > > 17 февр. 2017 г. 11:34 пользователь "Alexey Goncharuk" <
> > > alexey.goncha...@gmail.com> написал:
> > >
> > > Alexander,
> > >
> > > This change is not applicable for GridFutureAdapter because resFlag
> > can
> > > have 3 values there.
> > >
> > > 2017-02-16 19:58 GMT+03:00 Александр Меньшиков <
> sharple...@gmail.com
> > >:
> > >
> > > > Hello.
> > > >
> > > > I propose to do refactoring of classes "GridFinishedFuture" and
> > > > "GridFutureAdapter". There is field "resFlag" which can equals
> > "ERR = 1"
> > > or
> > > > "RES = 2". So I can replace it to one "bool haveResult" field.
> > > >
> > > > If there are no objections, I'm ready to proceed. If you find
> more
> > such
> > > > classes, please write about them.
> > > >
> > >
> >
> >
> >
> > --
> > Vladislav Pyatkov
> >
> 
> 
> >>>
> >>
> >
> >
> > --
> > Vladislav Pyatkov
> >
>

Re: IGNITE-603

[Yakov Zhdanov]

Denis, I can't say for sure, but the fact test was commented out for a long
time is suspicious.

Alexander, can you please uncomment, fix all the compilation errors and
update the ticket with test run results. Make sure you have
modules/ext-data projects built and all paths mentioned
in modules/core/src/test/config/tests.properties are valid (you will need
to set IGNITE_HOME env var most probably)

--Yakov

2017-02-13 23:10 GMT+03:00 Denis Magda :

> Hi Alexander,
>
> Looks like the test is commented for a while. GridDeploymentMode has
> already been renamed to DeploymentMode.
>
> Yakov, is this test still relevant for the compute grid?
>
> —
> Denis
>
> > On Feb 13, 2017, at 5:45 AM, Александр Меньшиков 
> wrote:
> >
> > Hello, everyone.
> >
> > I think the commented-out method "processSize2Test" can be removed. There
> > aren't class "GridDeploymentMode" which used in arguments.
> >
> > Do you agree with me?
>
>

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

[Yakov Zhdanov]

Denis, I did not get your last message. What did users expect from changing
hbFreq?

--Yakov

2017-02-28 4:08 GMT+03:00 Dmitriy Setrakyan :

> Yakov, what do you think?
>
> On Mon, Feb 27, 2017 at 4:17 PM, Denis Magda  wrote:
>
> > Frankly, I decided to initiate this discussion after talking to many
> > Apache Ignite users who had initially thought that TcpDiscoverySpi.
> heartbeatsFrequency
> > manages the heartbeats and they had tried to tweak it not getting a
> desired
> > outcome. Even more, TcpDiscoverySpi.heartbeatsFrequenc’s javadoc already
> > states that this is for metrics frequency only but looks like the guys
> > hadn’t note this.
> >
> > So, personally, yes I would break the compatibility here which is fine to
> > do in 2.0.
> >
> > —
> > Denis
> >
> > > On Feb 27, 2017, at 3:59 PM, Dmitriy Setrakyan 
> > wrote:
> > >
> > > To me it sounds rather as an aesthetic change. Is it really worth
> > breaking
> > > the API for this?
> > >
> > > On Mon, Feb 27, 2017 at 3:30 PM, Denis Magda 
> wrote:
> > >
> > >> The heartbeats frequency has to be lower than the failure detection
> > >> timeout. This is why we decided to calculate the former basing on a
> > value
> > >> set for the latter rather than making a user to adjust both properties
> > >> properly. This is how both parameters became related some time ago :)
> > >>
> > >> Honestly, I don’t think that the javadoc improvement will make things
> > >> clearer for the users. Hope you will agree that people pay attention
> to
> > the
> > >> naming first and, only if the naming makes sense to them, learn more
> > about
> > >> the details referring to the javadoc.
> > >>
> > >> —
> > >> Denis
> > >>
> > >>> On Feb 27, 2017, at 2:59 PM, Dmitriy Setrakyan <
> dsetrak...@apache.org>
> > >> wrote:
> > >>>
> > >>> Hm... I don't think that heartbeat frequency has to be associated
> with
> > >>> failure detection. What if we just update the javadoc for this
> > parameter,
> > >>> stating that it has to do with metrics update only?
> > >>>
> > >>> On Mon, Feb 27, 2017 at 11:44 AM, Denis Magda 
> > wrote:
> > >>>
> >  Igniters,
> > 
> >  Long time ago we updated the logic in discovery SPI that issues
> > >> heartbeats
> >  messages from one node to another. Presently, heartbeats frequency
> is
> >  calculated basing on IgniteConfiguration.failureDetectionTimeout
> > >> meaning
> >  that TcpDiscoverySpi.heartbeatsFrequency has nothing to do with
> >  heartbeats frequency at all.
> > 
> >  TcpDiscoverySpi.heartbeatsFrequency defines a frequency for metrics
> >  message. So, I propose to rename this method in Apache Igntie 2.0 to
> >  something more meaningful like TcpDiscoverySpi.
> > metricsUpdateFrequency?
> > 
> >  Do you agree? Alternatives thoughts?
> > 
> >  —
> >  Denis
> > >>
> > >>
> >
> >
>

[GitHub] ignite pull request #1581: IGNITE-1094 Ignite.createCache(CacheConfiguration...

[voipp]

GitHub user voipp opened a pull request:

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

IGNITE-1094 Ignite.createCache(CacheConfiguration) hangs if some exception 
occurs during cache initialization



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

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

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

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


commit d5dfb98af424db47bc67919c6d332ff335477f08
Author: sevdokimov 
Date:   2015-07-04T14:38:36Z

# IGNITE-1094 Add test.

commit ef77a55874dad3b5f99134f0d1e6e4901ac424c1
Author: voipp 
Date:   2017-02-28T09:45:47Z

IGNITE-1094 handling cache start exception




---
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-4713 : refactoring of GridFinishedFuture and GridFutureAdapter

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

Sorry, I mean I want to do fast work on this issue (not make code faster).
Your code is strange. You can see my view in my local temp PR:

https://github.com/SharplEr/ignite/pull/4/files

This is what I'm meaning.

I suppose "volatile" is not need here, because right now if
GridFutureAdapter#onDone() called in another thread than
GridFutureAdapter#get0, it will produce AssertionError.



2017-02-28 16:57 GMT+03:00 Vladislav Pyatkov :

> Alexander,
>
> Are you sure, which it will be faster?
> The condition
>
> resFlag == RES and resFlag == ERR
>
> should be more complicated... like something this:
>
> getState() != 0 &&  !resFlag and getState() != 0 &&  resFlag
>
> But unlike getState(), restFag is not volatile...
>
> On Tue, Feb 28, 2017 at 4:26 PM, Александр Меньшиков  > wrote:
>
>> Alexey, Vladislav, are you agree with me, or not? I want to do it faster
>> and move on.
>>
>> 2017-02-17 17:36 GMT+03:00 Александр Меньшиков :
>>
>>> We can check "onDone" method was called with using getState() method. If
>>> getState()!=0 then  resFlag!=0. Just look at code.
>>>
>>>
>>> 2017-02-17 17:12 GMT+03:00 Александр Меньшиков :
>>>
 Like I said, if "resFlag==0" (of course 0 came from initialization)
 means "you still haven't called the method onDone()", better make it clear.



 2017-02-17 14:48 GMT+03:00 Vladislav Pyatkov :

> Alexander,
>
> I think, the resFlag will be initiated as 0 (new GridFutureAdapter()),
> but
> 1 and 2 states will be acquired on live.
>
>
> On Fri, Feb 17, 2017 at 1:56 PM, Александр Меньшиков <
> sharple...@gmail.com>
> wrote:
>
> > Alexey,
> >
> > I see only one place where writes in resFlag:
> >
> > if (err != null) {
> > resFlag = ERR;
> > this.res = err;
> > }
> > else {
> > resFlag = RES;
> > this.res = res;
> > }
> >
> > And the comparison with only two values: "ERR" and "RES". Except
> "assert
> > resFlag != 0;". So if this "assert" protect from call "get0" before
> call
> > "onDone" I think will be clearer to set some ready flag or use
> "enum" type.
> > And throw IllegalStateException if condition is false, because right
> now
> > developer will not get clear error massage.
> >
> > 17 февр. 2017 г. 11:34 пользователь "Alexey Goncharuk" <
> > alexey.goncha...@gmail.com> написал:
> >
> > Alexander,
> >
> > This change is not applicable for GridFutureAdapter because resFlag
> can
> > have 3 values there.
> >
> > 2017-02-16 19:58 GMT+03:00 Александр Меньшиков  >:
> >
> > > Hello.
> > >
> > > I propose to do refactoring of classes "GridFinishedFuture" and
> > > "GridFutureAdapter". There is field "resFlag" which can equals
> "ERR = 1"
> > or
> > > "RES = 2". So I can replace it to one "bool haveResult" field.
> > >
> > > If there are no objections, I'm ready to proceed. If you find more
> such
> > > classes, please write about them.
> > >
> >
>
>
>
> --
> Vladislav Pyatkov
>


>>>
>>
>
>
> --
> Vladislav Pyatkov
>

Re: IGNITE-824: [Test] GridRandomSelfTest # testPerformance was disabled.

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

Yakov, please look at PR. It's simple removing.

2017-02-21 19:29 GMT+03:00 Александр Меньшиков :

> Done.
>
> PR inside:
> https://issues.apache.org/jira/browse/IGNITE-824
>
>
> 2017-02-21 13:04 GMT+03:00 Yakov Zhdanov :
>
>> Alexander, you can remove the test and resolve the issue.
>>
>> --Yakov
>>
>> 2017-02-20 17:43 GMT+03:00 Александр Меньшиков :
>>
>> > Do we still need this test? Can I remove it?
>> >
>>
>
>

Re: IGNITE-4713 : refactoring of GridFinishedFuture and GridFutureAdapter

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

Alexey, Vladislav, are you agree with me, or not? I want to do it faster
and move on.

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

> We can check "onDone" method was called with using getState() method. If
> getState()!=0 then  resFlag!=0. Just look at code.
>
>
> 2017-02-17 17:12 GMT+03:00 Александр Меньшиков :
>
>> Like I said, if "resFlag==0" (of course 0 came from initialization) means
>> "you still haven't called the method onDone()", better make it clear.
>>
>>
>>
>> 2017-02-17 14:48 GMT+03:00 Vladislav Pyatkov :
>>
>>> Alexander,
>>>
>>> I think, the resFlag will be initiated as 0 (new GridFutureAdapter()),
>>> but
>>> 1 and 2 states will be acquired on live.
>>>
>>>
>>> On Fri, Feb 17, 2017 at 1:56 PM, Александр Меньшиков <
>>> sharple...@gmail.com>
>>> wrote:
>>>
>>> > Alexey,
>>> >
>>> > I see only one place where writes in resFlag:
>>> >
>>> > if (err != null) {
>>> > resFlag = ERR;
>>> > this.res = err;
>>> > }
>>> > else {
>>> > resFlag = RES;
>>> > this.res = res;
>>> > }
>>> >
>>> > And the comparison with only two values: "ERR" and "RES". Except
>>> "assert
>>> > resFlag != 0;". So if this "assert" protect from call "get0" before
>>> call
>>> > "onDone" I think will be clearer to set some ready flag or use "enum"
>>> type.
>>> > And throw IllegalStateException if condition is false, because right
>>> now
>>> > developer will not get clear error massage.
>>> >
>>> > 17 февр. 2017 г. 11:34 пользователь "Alexey Goncharuk" <
>>> > alexey.goncha...@gmail.com> написал:
>>> >
>>> > Alexander,
>>> >
>>> > This change is not applicable for GridFutureAdapter because resFlag can
>>> > have 3 values there.
>>> >
>>> > 2017-02-16 19:58 GMT+03:00 Александр Меньшиков :
>>> >
>>> > > Hello.
>>> > >
>>> > > I propose to do refactoring of classes "GridFinishedFuture" and
>>> > > "GridFutureAdapter". There is field "resFlag" which can equals "ERR
>>> = 1"
>>> > or
>>> > > "RES = 2". So I can replace it to one "bool haveResult" field.
>>> > >
>>> > > If there are no objections, I'm ready to proceed. If you find more
>>> such
>>> > > classes, please write about them.
>>> > >
>>> >
>>>
>>>
>>>
>>> --
>>> Vladislav Pyatkov
>>>
>>
>>
>

Re: Remove CacheAtomicWriteOrderMode.CLOCK mode.

[Andrey Gura]

Maxim,

Yes, this setting doesn't make sense anymore. So we need remove all
related methods.

Also there is component called GridClockSyncProcessor that also should
be removed. It will lead to removing globalTime field from
GridCacheVersion class and some related methods.

On Tue, Feb 28, 2017 at 3:21 PM, Kozlov Maxim  wrote:
> Valentin,
>
> Then there is no need for setting CacheConfiguration.atomicWriteOrderMode. 
> What do you think, remove it and and related methods?
>
>> 28 февр. 2017 г., в 2:49, Valentin Kulichenko 
>>  написал(а):
>>
>> Hi Max,
>>
>> In case we remove the CLOCK mode, I think we should remove the enum too, as
>> well as configuration properties and other code using this enum. Having
>> enum with one value doesn't make sense to me.
>>
>> -Val
>>
>> On Mon, Feb 27, 2017 at 5:09 AM, Kozlov Maxim  wrote:
>>
>>> Hi Igniters,
>>>
>>> After remove CLOCK mode, CacheAtomicWriteOrderMode enum contains now only
>>> one value PRIMARY. Andrey Gura, proposition remove
>>> CacheAtomicWriteOrderMode enum. Will there be something special for this
>>> purpose is enum?
>>>
>>> jira: https://issues.apache.org/jira/browse/IGNITE-4587 <
>>> https://issues.apache.org/jira/browse/IGNITE-4587>
>>>
>>> --
>>> Best Regards,
>>> Max K.
>>>
>>>
>>>
>>>
>>>
>
> --
> Best Regards,
> Max K.
>
>
>
>

Re: Remove CacheAtomicWriteOrderMode.CLOCK mode.

[Kozlov Maxim]

Valentin,

Then there is no need for setting CacheConfiguration.atomicWriteOrderMode. What 
do you think, remove it and and related methods?

> 28 февр. 2017 г., в 2:49, Valentin Kulichenko  
> написал(а):
> 
> Hi Max,
> 
> In case we remove the CLOCK mode, I think we should remove the enum too, as
> well as configuration properties and other code using this enum. Having
> enum with one value doesn't make sense to me.
> 
> -Val
> 
> On Mon, Feb 27, 2017 at 5:09 AM, Kozlov Maxim  wrote:
> 
>> Hi Igniters,
>> 
>> After remove CLOCK mode, CacheAtomicWriteOrderMode enum contains now only
>> one value PRIMARY. Andrey Gura, proposition remove
>> CacheAtomicWriteOrderMode enum. Will there be something special for this
>> purpose is enum?
>> 
>> jira: https://issues.apache.org/jira/browse/IGNITE-4587 <
>> https://issues.apache.org/jira/browse/IGNITE-4587>
>> 
>> --
>> Best Regards,
>> Max K.
>> 
>> 
>> 
>> 
>> 

--
Best Regards,
Max K.

[GitHub] ignite pull request #1580: GridGain 1.9.1

[devozerov]

GitHub user devozerov opened a pull request:

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

GridGain 1.9.1



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

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

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

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


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

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

commit ce83715123d9ac3c1939e154318fce25d387bfed
Author: Pavel Tupitsyn 
Date:   2016-12-20T12:32:39Z

IGNITE-4359 .NET: Support DateTime properties in LINQ

commit d92b88f12fa2949a7ab0b205c8d2fcbfd1042f11
Author: Pavel Tupitsyn 
Date:   2016-12-20T13:01:22Z

IGNITE-4359 .NET: Fix Java timezone setting in tests

commit 072b9c26dda4eb7a39d095d33c08d1611c891444
Author: devozerov 
Date:   2016-12-21T10:08:30Z

IGNITE-4469: Hadoop: set default value of offheap memory page and shuffle 
messages to 1Mb.

commit 121f034e5739dcc7dd9c9577c9a437acaf710a19
Author: devozerov 
Date:   2017-01-05T09:00:49Z

Merge branch 'ignite-1.8.2' into ignite-1.8.3

commit 494cf88209b196f2677e26f468aab1f98d791217
Author: devozerov 
Date:   2017-01-05T09:05:04Z

Merge branch 'ignite-1.7.5' into ignite-1.8.3

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryObjectExImpl.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/query/GridQueryProcessor.java
#   
modules/platforms/dotnet/Apache.Ignite.Benchmarks/Properties/AssemblyInfo.cs
#   
modules/platforms/dotnet/Apache.Ignite.Core.Tests.NuGet/Properties/AssemblyInfo.cs
#   
modules/platforms/dotnet/Apache.Ignite.Core.Tests/Cache/Query/CacheQueriesCodeConfigurationTest.cs
#   
modules/platforms/dotnet/Apache.Ignite.Core.Tests/Properties/AssemblyInfo.cs
#   modules/platforms/dotnet/Apache.Ignite.NLog/Properties/AssemblyInfo.cs
#   modules/platforms/dotnet/Apache.Ignite/Properties/AssemblyInfo.cs
#   
modules/platforms/dotnet/examples/Apache.Ignite.Examples/Properties/AssemblyInfo.cs
#   
modules/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/Properties/AssemblyInfo.cs

commit ac92bdb44ed0fb02893c1e7e9df4443a0a26d331
Author: Ivan Veselovskiy 
Date:   2016-12-19T08:57:00Z

IGNITE-3966: Hadoop: add Hadoop native library to Java arguments 
automatically. This closes #1320.

commit 1776e9eb04895bbb870f7c6aa89ca96db2af31b7
Author: tledkov-gridgain 
Date:   2016-12-29T08:14:10Z

IGNITE-4458: Hadoop: "striped" shuffle mode is default from now on. This 
closes #1390.

commit e7d781ee3221107d9a819dd70cb5776558a59e2a
Author: devozerov 
Date:   2017-01-05T08:30:42Z

IGNITE-4516: Hadoop: implemented optional compression for remote shuffle 
output. This closes #1399.

commit b6005b07b3e28907c8ff5cb6ebcce25bdb23bb48
Author: devozerov 
Date:   2017-01-05T11:48:06Z

IGNITE-4461: Hadoop: added automatic resolution of "raw" comparator for 
Text class.

commit 07752ec85dc3bf18297b728f9a31185d44ad3687
Author: sboikov 
Date:   2017-01-11T10:51:23Z

Improved cache.get benchmarks.

commit 660cd1e072496c323f5bdfc797f2a7cb7d74480d
Author: sboikov 
Date:   2017-01-11T14:34:46Z

Added cache.getAll benchmarks for offheap cache.

commit 074a4a08012822f3404807015bc63052c20e7439
Author: sboikov 
Date:   2017-01-11T14:54:55Z

Added cache.getAll benchmarks for offheap cache.

commit 1820eb3135c44d6768d53b95d69c2a93c7759b6f
Author: sboikov 
Date:   2017-01-11T15:09:42Z

Added cache.putAll benchmarks for offheap cache.

commit e04d83c4911bbd3e18f03ee1e80a99cd49fae87f
Author: sboikov 
Date:   2017-01-11T15:15:53Z

Added cache.putAll benchmarks for offheap cache.

commit 71a76c81530d1aa38525fd78a90b065b6e19a6bb
Author: Andrey V. Mashenkov 
Date:   2017-01-19T10:29:55Z

IGNITE-4550: Move service deployment to certain test. This closes #1437.

commit 476b089b1dd4b4c5d3b6ae21e1b3b2c010c086ac
Author: tledkov-gridgain 
Date:   2017-01-20T14:33:34Z

IGNITE-4507: Hadoop: added direct output support for combiner. This closes 
#1434.

commit 065fe4525cc46a46f65dd40af6f4be9f034c0de2
Author: devozerov 
Date:   2017-01-20T14:36:02Z

Merge remote-tracking branch 'upstream/ignite-1.8.3' into ignite-1.8.3

commit 

REVIEW IGNITE-2552 EvictionPolicies refactored, logic changed

[ALEKSEY KUZNETSOV]

Plz, review my PR :
http://reviews.ignite.apache.org/ignite/review/IGNT-CR-98
or https://github.com/apache/ignite/pull/1545
-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: PR IGNITE-1178 fix for NPE in GridCacheProcessor.onKernalStop()

[ALEKSEY KUZNETSOV]

plz review ticket again

пн, 20 февр. 2017 г. в 11:14, Alexey Goncharuk :

> Thanks, Aleksey,
>
> I will take a look this week.
>
> --AG
>
> 2017-02-20 10:25 GMT+03:00 ALEKSEY KUZNETSOV :
>
> > Hi! Review my PR again, plz - https://github.com/apache/ignite/pull/1517
> >
> > пт, 17 февр. 2017 г. в 14:44, ALEKSEY KUZNETSOV <
> alkuznetsov...@gmail.com
> > >:
> >
> > > thanx! my next PR review will be in up source
> > >
> > > пт, 17 февр. 2017 г. в 13:05, Alexey Goncharuk <
> > alexey.goncha...@gmail.com
> > > >:
> > >
> > > Aleksey,
> > >
> > > I added a comment on GitHub, however, the community is moving towards
> the
> > > UpSource review tool, so I suggest you open a PR review in Ignite
> > UpSource:
> > > http://reviews.ignite.apache.org/ignite/
> > >
> > > After you've registered, you should be able to open a review.
> > >
> > > --AG
> > >
> > > 2017-02-17 11:13 GMT+03:00 ALEKSEY KUZNETSOV  >:
> > >
> > > > Again, plz, review my PR :
> https://github.com/apache/ignite/pull/1517
> > > >
> > > > https://issues.apache.org/jira/browse/IGNITE-1178
> > > > --
> > > >
> > > > *Best Regards,*
> > > >
> > > > *Kuznetsov Aleksey*
> > > >
> > >
> > > --
> > >
> > > *Best Regards,*
> > >
> > > *Kuznetsov Aleksey*
> > >
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
> >
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

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

[Semyon Boikov]

Hi,

Thank you for reporting this bug, but it seems fix you suggested will not
work for HibernateReadWriteAccessStrategy since single thread local is
needed to use single cross-cache transaction.

I created JIRA issue: https://issues.apache.org/jira/browse/IGNITE-4760.

Thanks!

On Sun, Feb 26, 2017 at 12:25 PM, Cameron Braid 
wrote:

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

[jira] [Created] (IGNITE-4760) Hibernate L2 cache stores value in wrong cache

[Semen Boikov (JIRA)]

Semen Boikov created IGNITE-4760:


 Summary: Hibernate L2 cache stores value in wrong cache
 Key: IGNITE-4760
 URL: https://issues.apache.org/jira/browse/IGNITE-4760
 Project: Ignite
  Issue Type: Bug
  Components: Hibernate L2 cache
Reporter: Semen Boikov
 Fix For: 2.0


Issue is reported here:
http://apache-ignite-developers.2346864.n4.nabble.com/issue-with-Hibernate-2L-cache-region-factory-ignite-1-8-td14912.html

First it is necessary add JUnit test reproducing issue (see existing tests in 
IgniteHibernateTestSuite).

Currently Hibernate access strategies track updates using thread locals, and it 
looks like updates for different caches can be mixed. I think per-cache thread 
local can fix issue for HibernateNonStrictAccessStrategy, but per-cache thread 
local can not be used for HibernateReadWriteAccessStrategy, since it is assumed 
that all updates should be part of the same cross-cache ignite transaction.

So possible fix:
- use per-cache thread local for HibernateNonStrictAccessStrategy (or somehow 
track target cache in HibernateNonStrictAccessStrategy)
- use single thread local for HibernateReadWriteAccessStrategy



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

[jira] [Created] (IGNITE-4759) Rework pug html loader to pug loader

[Dmitriy Shabalin (JIRA)]

Dmitriy Shabalin created IGNITE-4759:


 Summary: Rework pug html loader to pug loader
 Key: IGNITE-4759
 URL: https://issues.apache.org/jira/browse/IGNITE-4759
 Project: Ignite
  Issue Type: Task
  Components: wizards
Reporter: Dmitriy Shabalin


Need change pug html loader to pug loader for use native require option in 
templates to load images and etc with webpack loaders



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

INGITE-4302 PR is ready for review

[Sergey Chugunov]

Hello Igniters,

I finished my work on IGNITE-4302
 *Exchange binary
metadata with discovery custom messages*, pull request
 is open, TC results

for it look good.

Please take a look; any comments and suggestions about quality of code are
welcome.

Thanks,
Sergey.

IGNITE-4758 - introducing cache memory policies

[Sergey Chugunov]

Hello Ignite devs,

I created new subtask 
under IGNITE-3477  with
my vision of how *MemoryPolicy* may be implemented.

In a nutshell my idea is as follows: instead of having only one instance of
*PageMemory* and managing a mapping [cacheId->pageMemory region] I suggest
introducing separate *PageMemory* instance (and corresponding *FreeList*
and *ReuseList* structures) for each *MemoryPolicy* configuration.
This instance will be stored in individual cache contexts instead of shared
cache context as it is right now.

I think this design is a very natural extension of *PageMemory* concept and
should not introduce any performance degradation as no changes are
introduced into *PageMemory* implementation itself.

Please share any thoughts or concerns about suggested design in this thread
or in comments under the subtask
.

Thanks,
Sergey.