Re: PR IGNITE-2845 Get operation might ignore entry update from EntryProcessor

[ALEKSEY KUZNETSOV]

Do it in scope of 3471, and plz change status in my ticket accordingly :
https://issues.apache.org/jira/browse/IGNITE-2845

вт, 21 февр. 2017 г. в 23:24, Alexander Fedotov <
alexander.fedot...@gmail.com>:

> Hi,
>
> Here are my findings.
> The case is related to IGNITE-3471 and will be done in its scope.
> I've tried a simple fix that enables missed checks for keys for which there
> are entry processors
> and it has worked. Still, a more elaborate solution is required that
> accounts the entry modification type,
> i.e. CREATE in this case, because the simple fix leads to entry processors
> being called two times.
> Shall I prepare a fix for
> https://issues.apache.org/jira/browse/IGNITE-2845 or
> do it in scope of IGNITE-3471?
>
> On Tue, Feb 21, 2017 at 8:26 PM, Alexander Fedotov <
> alexander.fedot...@gmail.com> wrote:
>
> > Hi,
> >
> > Looks like that it's actually related to https://issues.apache.org/jira
> > /browse/IGNITE-3471.
> > I'll take a look at it. I would suggest, it is by design behavior.
> > Let me check.
> >
> > On Tue, Feb 21, 2017 at 8:13 PM, Alexey Goncharuk <
> > alexey.goncha...@gmail.com> wrote:
> >
> >> Aleksey,
> >>
> >> I am not sure your change is a correct fix. The whole point of
> >> EntryProcessor is to avoid sending values over the network and send only
> >> entry processor result, which is typically smaller than the value stored
> >> in
> >> a cache.
> >>
> >> Looks like this case is covered by the following ticket:
> >> https://issues.apache.org/jira/browse/IGNITE-3471. Please cooperate
> with
> >> Alexandr to make sure your test is included in his fix.
> >>
> >> --AG
> >>
> >> 2017-02-21 14:44 GMT+03:00 ALEKSEY KUZNETSOV  >:
> >>
> >> > PR redy, welcome to review :
> https://github.com/apache/ignite/pull/1557
> >> >
> >> > https://issues.apache.org/jira/browse/IGNITE-2845
> >> > --
> >> >
> >> > *Best Regards,*
> >> >
> >> > *Kuznetsov Aleksey*
> >> >
> >>
> >
> >
> >
> > --
> > Kind regards,
> > Alexander.
> >
>
>
>
> --
> Kind regards,
> Alexander.
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

[jira] [Created] (IGNITE-4740) Service could be initialized twice on concurrent cancel and discovery event

[Dmitry Karachentsev (JIRA)]

Dmitry Karachentsev created IGNITE-4740:
---

 Summary: Service could be initialized twice on concurrent cancel 
and discovery event
 Key: IGNITE-4740
 URL: https://issues.apache.org/jira/browse/IGNITE-4740
 Project: Ignite
  Issue Type: Bug
  Components: managed services
Affects Versions: 1.8
Reporter: Dmitry Karachentsev
Assignee: Dmitry Karachentsev
 Fix For: 2.0


In case of concurrent service cancel and discovery event, for example, applying 
continuous query, may cause double init() and execute() service method 
invocation.

Fix should consist at least in filtering such DiscoveryCustomEvent in 
GridServiceProcessor.TopologyListener.
The best solution is guarantee that despite of any discovery event service 
won't be intialized more than once.



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

[jira] [Created] (IGNITE-4739) CacheJdbcPojoStore: Add upsert support for PostgreSQL dialect

[Andrey Novikov (JIRA)]

Andrey Novikov created IGNITE-4739:
--

 Summary: CacheJdbcPojoStore: Add upsert support for PostgreSQL 
dialect
 Key: IGNITE-4739
 URL: https://issues.apache.org/jira/browse/IGNITE-4739
 Project: Ignite
  Issue Type: Improvement
  Components: SQL
Reporter: Andrey Novikov
Priority: Minor


https://wiki.postgresql.org/wiki/What's_new_in_PostgreSQL_9.5#INSERT_..._ON_CONFLICT_DO_NOTHING.2FUPDATE_.28.22UPSERT.22.29



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

[GitHub] ignite pull request #1510: IGNITE-4226: Redis SET command to handle expirati...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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: Major release 2.0 and compilation

[Dmitriy Setrakyan]

Thanks, Taras! I think this definitely should be included in the release
notes and somewhere in the documentation.

On Tue, Feb 21, 2017 at 2:50 AM, Taras Ledkov  wrote:

> I've updated the issue: https://issues.apache.org/jira/browse/IGNITE-3469
> with two lists of deprecated API: public and private.
>
> Please take a look. I would create sub tasks for each to make review
> simpler then one huge patch that contains the whole refactoring.
>
> The list of the deprecated public class / methods / properties:
>
> - two methods IgniteCluster.mapKeyToNode - the removing is simple because
> its are used rare;
> - IgniteCache.randomEntry - the removing is simple because it is used rare;
> - The system flags:
> - IGNITE_BINARY_SORT_OBJECT_FIELDS;
> - IGNITE_BINARY_DONT_WRAP_TREE_STRUCTURES;
> - IGNITE_MIN_BUFFERED_COMMUNICATION_MSG_CNT - not used in the
> projects now.
> - CacheTypeMetadata;
> - Classes related with AffinityNodeHashResolver;
> - Backup filters for affinity functions;
> - RandomEvictionPolicy;
> - ContinuousQuery.setRemoteFilter;
> - CacheStore.sessionEnd;
> - CacheAbstractJdbcStore.translateFields;
> - CacheJdbcPojoStoreFactory.setDataSource;
> - CacheConfiguration properties: transactionManagerLookupClassName and
> {rebalanceThreadPoolSize}};
> - ConnectorConfiguration.sslContextFactory property;
> - FileSystemConfiguration properties:
> - fragmentizerLocalWritesRatio;
> - trashPurgeTimeout;
> - dualModePutExecutorService;
> - dualModePutExecutorServiceShutdown;
> - dualModeMaxPendingPutsSize;
> - IgniteConfiguration properties:
> - nodeId;
> - DFLT_PUBLIC_KEEP_ALIVE_TIME;
> - DFLT_PUBLIC_THREADPOOL_QUEUE_CAP;
> - DFLT_SYSTEM_MAX_THREAD_CNT;
> - DFLT_SYSTEM_KEEP_ALIVE_TIME;
> - DFLT_UTILITY_KEEP_ALIVE_TIME;
> - DFLT_SYSTEM_THREADPOOL_QUEUE_CAP;
> - TransactionConfiguration properties:
> - txSerializableEnabled;
> - txManagerLookupClassName;
> - Several methods at the IgfsPath class: empty constructor, root() and
> isSame methods;
> - IgniteSpiContext: methods addMessageListener, removeMessageListener;
> - TcpCommunicationSpi properties:
> - connectionBufferSize;
> - connectionBufferFlushFrequency;
> - minimumBufferedMessageCount;
> - StreamTupleExtractor class and relations;
> - ignite-hadoop: Several constructors of the IgniteHadoopIgfsSecondaryFileS
> ystem;
> - ignite-yarn: ApplicationMaster.getContainers().
>
> The list of the deprecated private class / methods / properties:
>
> - Classes are retated to the GridSslContextFactory;
> - JdbcConnection related classes;
> - GridCacheUtils.cheatCache;
> - GridCacheCommittedTxInfo;
> - GridDistributedTxFinishRequest: syncCommit, syncRollback;
> - GridDhtPartitionDemander: demandLock, dmIdx, worker, SupplyMessage,
> DemandWorker;
> - One of the constructors of the GridDhtPartitionFullMap;
> - GridDhtPartitionMap;
> - GridDhtPartitionSupplier old listeners & old demand message;
> - AffinityTask.affinityKey()
> - GridQueryRequest;
> - One of the constructors of GridLeanSet;
> - Several methods at the IgniteUtils;
> - Several methods at the GridFunc;
> - GridTupleV;
> - PlatformDotNetBinaryTypeConfiguration.isKeepDeserialized();
> - ServerImpl.RingMessageWorker.processNodeAddedMessage;
> - TcpDiscoverySpi.versionCheckFailed;
>
>
> On 08.12.2016 1:04, Denis Magda wrote:
>
>> I would remove as much as possible and prepare a migration guide as
>> Sergey K. suggests below.
>>
>> In any case, we will stick to the flexible approach. As the next step I
>> would split all the existed APIs in 2 groups. The first group will be for
>> the APIs that will be deleted and we will provide instructions in the
>> migration guide on how to migrate from them. The second group will be for
>> those that will be left.
>>
>> Actually, there is an already existed ticket for this
>> https://issues.apache.org/jira/browse/IGNITE-3469 <
>> https://issues.apache.org/jira/browse/IGNITE-3469>
>>
>> —
>> Denis
>>
>> On Dec 7, 2016, at 10:12 AM, Sergey Kozlov  wrote:
>>>
>>> I would remind that Apache Ignite 1.0.0 has been released 20 months ago
>>> and
>>> probably 2.0 will be rolled out close to the second anniversary of
>>> initial
>>> release. It's right time to remove deprecated API and provide for users
>>> the
>>> clear ways for migration 1.x to 2.0.
>>>
>>> I think we could create a wiki page for users who can recompile their
>>> applications, list all deprecated API calls and provide migration's
>>> tips/tricks from deprecated features to new ones (something like the
>>> table
>>> with columns "Deprecated API call for 1.x", "API call for
>>> 2.0/workaround").
>>>
>>>
>>>
>>> On Wed, Dec 7, 2016 at 11:36 AM, Yakov Zhdanov 
>>> wrote:
>>>
>>> Agree with Vladimir that we should use flexible approach and should avoid
 any possible harm here, but cleaning out most of deprecations is the
 way to
 go, IMO. There are about 90 

Re: IGNITE-2741 - spring session design

[Rishi Yagnik]

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 
> > 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 
> >> 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 
> >>> 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
> > much as
> > possible.
> >
> > Do you have any code that reproduces the problem you had and how you
> > tried
> > to utilize current web session clustering? Can you share it with us?
> >
> > -Val
> >
> > On Tue, Feb 14, 2017 at 11:28 AM, Rishi Yagnik <
> rishiyag...@gmail.com>
> > wrote:
> >
> > > Hi Val,
> > >
> > > I am working on SB platform with spring security and we found out
> > that the
> > > web session filter ignite provides does not work for session
> > management on
> > > 2 node spring boot cluster.
> > >
> > > Somehow, spring security filter kicks in result in some weird
> errors
> > with
> > > web session filter.
> > >
> > > So making compatible with spring security somehow, we need to write
> > > implementation on spring session.
> > >
> > > Do you have any test cases that says web session filter would work
> > with
> > > spring security on boot platform ?
> > >
> > > Thanks,
> > >
> > >
> > > On Tue, Feb 14, 2017 at 1:03 PM, Valentin Kulichenko <
> > > valentin.kuliche...@gmail.com> wrote:
> > >
> > > > Hi Rishi,
> > > >
> > > > Can you please take a look at web session clustering feature [1]
> > provided
> > > > by Ignite? I'm looking at Spring Session docs and it seems to me
> > it does
> > > > exactly the same - replaces HttpSession with custom
> implementation
> > that
> > > has
> > > > a backend storage. If it doesn't provide any additional API or
> > > > functionality, I'm not sure I understand the benefit of this
> > feature.
> > > >
> > > > Let me know if I'm missing something.
> > > >
> > > > [1] https://apacheignite-mix.readme.io/docs/web-session-
> clustering
> > > >
> > > > -Val
> > > >
> > > > On Mon, Feb 13, 2017 at 2:41 PM, Rishi Yagnik <
> > rishiyag...@gmail.com>
> > > > wrote:
> > > >
> > > > > I would like to discuss session replication / fail 

Re: cache metadata progapagation

[Dmitriy Setrakyan]

Thanks, Val. I think it is worthwhile to change the ticket description with
full context at this point. Also, the title of the ticket should not have
CacheStore, but CacheConfiguration. Can you do it?

On Tue, Feb 21, 2017 at 2:38 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Dmitry,
>
> I believe you're talking about this issue:
> https://issues.apache.org/jira/browse/IGNITE-1903
>
> I just added a comment there with some thoughts about how we can improve
> this.
>
> -Val
>
> On Mon, Feb 20, 2017 at 12:37 AM, Alexey Goncharuk <
> alexey.goncha...@gmail.com> wrote:
>
> > Dmitriy,
> >
> > What do you mean by deploying cache metadata? The node filter itself must
> > be deserialized on each node because we need to evaluate it. As for the
> > CacheConfiguration, we do not need to deserialize the configuration on
> > every node, this will be a good change for Ignite 2.0.
> >
> > 2017-02-16 23:14 GMT+03:00 Dmitriy Setrakyan :
> >
> > > Igniters,
> > >
> > > I believe that we are not propagating cache metadata correctly, but I
> > want
> > > to confirm it with the community first.
> > >
> > > Currently, it is possible in Ignite to split the cluster into logical
> > > groups, and deploy caches only on certain nodes using NodeFilters. For
> > > example, CacheA will reside only on Nodes 1, 2, and 3, and CacheB will
> > > reside only on nodes 4 and 5. However, even in this case, it looks like
> > the
> > > cache metadata for both caches will be deployed on all the nodes.
> > >
> > > It looks like the correct approach would be to honor the NodeFilter
> for a
> > >  cache whenever deploying the cache metadata. Is there a reason for the
> > > metadata to be deployed on all the nodes?
> > >
> > > D.
> > >
> >
>

Re: Entry filter in IgniteCache#loadCache

[Dmitriy Setrakyan]

Val, do you think this change will be worth breaking backward API
compatibility?

On Tue, Feb 21, 2017 at 2:45 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> On Mon, Feb 20, 2017 at 12:23 PM, Dmitriy Setrakyan  >
> wrote:
>
> > On Sat, Feb 18, 2017 at 12:51 PM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > > Igniters,
> > >
> > > Currently IgniteCache.loadCache has optional entry filter that can be
> > > passed as an argument. It seems to be redundant because:
> > >
> > >- Filtering that is done by this filter can be as well implemented
> > >within CacheStore itself. Moreover, if the filtering can be done on
> DB
> > >level, it's better from performance standpoint.
> > >
> >
> > What if user configures our standard JDBC store? How will the customer
> > filtering logic be added in this case?
> >
>
> Our store accepts custom SQL queries. This should be enough to do any
> filtering and it's also better from performance standpoint.
>
>
> >
> >
> > >- In case filtering has to be dynamic (i.e. use does wants to
> provide
> > a
> > >predicate as an argument), generic arguments can be used.
> > >
> >
> > Not sure what you mean by "generic arguments". Can you explain?
> >
>
> I mean array of arguments passed to CacheStore.loadCache() method. Any
> arguments can be used there, including predicates.
>
>
> >
> >
> > >
> > > Having said that, this predicate doesn't add any value and therefore
> > > creates confusion. And frankly, I've never seen anyone using it. I
> > suggest
> > > to remove it completely in 2.0.
> > >
> >
> > I am not sure if I agree. Why break API compatibility here for no
> apparent
> > benefit?
> >
> >
> > >
> > > Thoughts?
> > >
> > > -Val
> > >
> >
>

[GitHub] ignite pull request #1567: IGNITE-4737: Update Apache Flink dependencies to ...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 #1567: IGNITE-4737: Update Apache Flink dependencies to ...

[shroman]

GitHub user shroman opened a pull request:

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

IGNITE-4737: Update Apache Flink dependencies to 1.2.0.



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

$ git pull https://github.com/shroman/ignite IGNITE-4737

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

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


commit 6ddf32ba54808fa7940f65059f7d4dbc1289b7fc
Author: shtykh_roman 
Date:   2017-02-22T02:37:12Z

IGNITE-4737: Update Apache Flink dependencies to 1.2.0.




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

Regex SQL functions

[Valentin Kulichenko]

Sergi,

I understand that we're going to upgrade H2 in Ignite 2.0. Can you please
check if this will automatically add support for regex functions (H2 has
them in the latest release)?

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

-Val

[jira] [Created] (IGNITE-4738) Support REGEXP_LIKE and REGEXP_REPLACE SQL functions

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-4738:
---

 Summary: Support REGEXP_LIKE and REGEXP_REPLACE SQL functions
 Key: IGNITE-4738
 URL: https://issues.apache.org/jira/browse/IGNITE-4738
 Project: Ignite
  Issue Type: Improvement
  Components: SQL
Affects Versions: 1.8
Reporter: Valentin Kulichenko
 Fix For: 2.0


These functions are supported by H2 in their latest version, but not in the 
version Ignite depends on. Most likely we just need to upgrade H2.



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

Re: Clean sitemap.xml for the website

[Denis Magda]

Hi Mauricio,

Thanks! I’ve reviewed and merged the changes.

—
Denis

> On Feb 20, 2017, at 9:26 AM, Mauricio Stekl  wrote:
> 
> Hello Igniters, 
> 
> Based on the SEO analysis we reported earlier, I have cleaned up the 
> sitemap.xml for the website, maintaining the amount of URLs to the minimum 
> recommended. I am attaching a patch with all the changes
> 
> Could any of the committers please apply this patch to the website repo?
> 
> Let me know if you have any question.
> 
> 
> Best,
> Mauricio Stekl
> 
> 
> 
> 
> 

Re: Locking of partition with affinityRun/affinityCall

[Denis Magda]

Taras, thanks. Looks good to merge.

—
Denis

> On Feb 20, 2017, at 4:43 AM, Taras Ledkov  wrote:
> 
> Denis,
> 
> I've fixed javadocs for affinityRun/affinityCall.
> 
> Please review the changes at the PR: 
> https://github.com/apache/ignite/pull/1550
> 
> 
> On 08.12.2016 12:06, Taras Ledkov wrote:
>> Denis,
>> 
>> The second point is absolutely correct.
>> The rebalancing isn't blocked. The partition will not be evicted while the 
>> partition is reserved.
>> 
>> I'll update javadoc ASAP.
>> 
>> 
>> On Wed, Nov 30, 2016 at 10:23 PM, Denis Magda > > wrote:
>> 
>>Taras,
>> 
>>There is a question in regards to the feature contributed by you
>>recently
>>https://issues.apache.org/jira/browse/IGNITE-2310
>>
>> 
>>The Java API doc says that the partition will not be migrated
>>while a job is being executed on a target node.
>> 
>>Does it mean that
>>- the rebalancing will be postponed in general or
>>- the rebalancing of the partition will be started, moving its
>>content to a new primary, but the partition will not be evicted
>>from the target node while the job is running
>> 
>>In my understanding the second point is correct and I’ve
>>documented the feature saying that the partition is not evicted
>>
>> http://apacheignite.gridgain.org/v1.7/docs/collocate-compute-and-data#affinity-call-and-run-methods
>>
>> 
>> 
>>Please clarify what’s true and update Java API doc if my current
>>understanding is correct.
>> 
>>—
>>Denis
>> 
>> 
> 
> -- 
> Taras Ledkov
> Mail-To: tled...@gridgain.com
> 

Re: IGNITE-3422 - ready for review

[Denis Magda]

Replied.

—
Denis

> On Feb 20, 2017, at 3:08 AM, Vladimir Ozerov  wrote:
> 
> Hi Vyacheslav,
> 
> Thank you for contribution. I reviewed implementation again and now I am in
> doubts whether our product would really benefit from it or not. See my
> comments in the ticket. I'de prefer Denis Magda to chime in and give his
> feedback first.
> 
> Vladimir.
> 
> On Wed, Feb 15, 2017 at 5:00 PM, Vyacheslav Daradur 
> wrote:
> 
>> Hello everyone.
>> 
>> Please, review implemented solution.
>> 
>> https://issues.apache.org/jira/browse/IGNITE-3422 - No way to control
>> object initialization during deserialization/unmarshalling
>> 
>> ci.tests 
>> 

Re: general question

[Denis Magda]

Hi,

What exactly do you observe and how do you configure it? As I understand the 
SPI should be called even if the peer-class-loading is disabled. I would 
suggest turning on logger’s debug mode for this implementation.

—
Denis

> On Feb 20, 2017, at 7:48 AM, ALEKSEY KUZNETSOV  
> wrote:
> 
> Hi! Why local deployment SPI is ignored, if peer class loading is disabled,
> and local deployment spi is enabled ?
> -- 
> 
> *Best Regards,*
> 
> *Kuznetsov Aleksey*

Re: Entry filter in IgniteCache#loadCache

[Valentin Kulichenko]

On Mon, Feb 20, 2017 at 12:23 PM, Dmitriy Setrakyan 
wrote:

> On Sat, Feb 18, 2017 at 12:51 PM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Igniters,
> >
> > Currently IgniteCache.loadCache has optional entry filter that can be
> > passed as an argument. It seems to be redundant because:
> >
> >- Filtering that is done by this filter can be as well implemented
> >within CacheStore itself. Moreover, if the filtering can be done on DB
> >level, it's better from performance standpoint.
> >
>
> What if user configures our standard JDBC store? How will the customer
> filtering logic be added in this case?
>

Our store accepts custom SQL queries. This should be enough to do any
filtering and it's also better from performance standpoint.


>
>
> >- In case filtering has to be dynamic (i.e. use does wants to provide
> a
> >predicate as an argument), generic arguments can be used.
> >
>
> Not sure what you mean by "generic arguments". Can you explain?
>

I mean array of arguments passed to CacheStore.loadCache() method. Any
arguments can be used there, including predicates.


>
>
> >
> > Having said that, this predicate doesn't add any value and therefore
> > creates confusion. And frankly, I've never seen anyone using it. I
> suggest
> > to remove it completely in 2.0.
> >
>
> I am not sure if I agree. Why break API compatibility here for no apparent
> benefit?
>
>
> >
> > Thoughts?
> >
> > -Val
> >
>

Re: cache metadata progapagation

[Valentin Kulichenko]

Dmitry,

I believe you're talking about this issue:
https://issues.apache.org/jira/browse/IGNITE-1903

I just added a comment there with some thoughts about how we can improve
this.

-Val

On Mon, Feb 20, 2017 at 12:37 AM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:

> Dmitriy,
>
> What do you mean by deploying cache metadata? The node filter itself must
> be deserialized on each node because we need to evaluate it. As for the
> CacheConfiguration, we do not need to deserialize the configuration on
> every node, this will be a good change for Ignite 2.0.
>
> 2017-02-16 23:14 GMT+03:00 Dmitriy Setrakyan :
>
> > Igniters,
> >
> > I believe that we are not propagating cache metadata correctly, but I
> want
> > to confirm it with the community first.
> >
> > Currently, it is possible in Ignite to split the cluster into logical
> > groups, and deploy caches only on certain nodes using NodeFilters. For
> > example, CacheA will reside only on Nodes 1, 2, and 3, and CacheB will
> > reside only on nodes 4 and 5. However, even in this case, it looks like
> the
> > cache metadata for both caches will be deployed on all the nodes.
> >
> > It looks like the correct approach would be to honor the NodeFilter for a
> >  cache whenever deploying the cache metadata. Is there a reason for the
> > metadata to be deployed on all the nodes?
> >
> > D.
> >
>

Re: PR IGNITE-2845 Get operation might ignore entry update from EntryProcessor

[Alexander Fedotov]

Hi,

Here are my findings.
The case is related to IGNITE-3471 and will be done in its scope.
I've tried a simple fix that enables missed checks for keys for which there
are entry processors
and it has worked. Still, a more elaborate solution is required that
accounts the entry modification type,
i.e. CREATE in this case, because the simple fix leads to entry processors
being called two times.
Shall I prepare a fix for https://issues.apache.org/jira/browse/IGNITE-2845 or
do it in scope of IGNITE-3471?

On Tue, Feb 21, 2017 at 8:26 PM, Alexander Fedotov <
alexander.fedot...@gmail.com> wrote:

> Hi,
>
> Looks like that it's actually related to https://issues.apache.org/jira
> /browse/IGNITE-3471.
> I'll take a look at it. I would suggest, it is by design behavior.
> Let me check.
>
> On Tue, Feb 21, 2017 at 8:13 PM, Alexey Goncharuk <
> alexey.goncha...@gmail.com> wrote:
>
>> Aleksey,
>>
>> I am not sure your change is a correct fix. The whole point of
>> EntryProcessor is to avoid sending values over the network and send only
>> entry processor result, which is typically smaller than the value stored
>> in
>> a cache.
>>
>> Looks like this case is covered by the following ticket:
>> https://issues.apache.org/jira/browse/IGNITE-3471. Please cooperate with
>> Alexandr to make sure your test is included in his fix.
>>
>> --AG
>>
>> 2017-02-21 14:44 GMT+03:00 ALEKSEY KUZNETSOV :
>>
>> > PR redy, welcome to review : https://github.com/apache/ignite/pull/1557
>> >
>> > https://issues.apache.org/jira/browse/IGNITE-2845
>> > --
>> >
>> > *Best Regards,*
>> >
>> > *Kuznetsov Aleksey*
>> >
>>
>
>
>
> --
> Kind regards,
> Alexander.
>



-- 
Kind regards,
Alexander.

Re: Maintaining documentation consistency on readme.io

[Denis Magda]

Igniters,

We’re approaching 1.9 release and some of you will be updating the 
documentation on readme.io. Let me remind you how the documentation has to be 
updated if you’re adding a feature that is missing in 1.8.

1) DO NOT create any new version of the document until the release. If you want 
to add any new document pertaining to the next release, create it within the 
document for the current version and keep the page hidden. 

If you need to update an existing page then clone it, name as 
{page-name-new-version}, refine and left hidden.

2) Send all the documentation updates for review to Denis Magda and Prachi Garg.

Documented on the wiki:
https://cwiki.apache.org/confluence/display/IGNITE/Documentation 


—
Denis

> On Oct 12, 2016, at 9:57 AM, Prachi Garg  wrote:
> 
> To make changes for the existing pages, creating a clone of the page would be 
> my suggestion too, and readme.io  provides this feature.
> 
> -P
> 
> On Wed, Oct 12, 2016 at 9:15 AM, Denis Magda  > wrote:
> We can create a copy of an existing page then and make it hidden. At the time 
> 1.8 gets released the page will become a primary one and the old one will be 
> removed.
> 
> Prachi, do you have other approaches in mind?
> 
> —
> Denis
> 
>> On Oct 12, 2016, at 1:39 AM, Alexey Kuznetsov > > wrote:
>> 
>> Hi,
>> 
>> +1 to Vova question.
>> How should I modify existing page if my modification intended for 1.8 
>> release?
>> 
>> 
>> On Wed, Oct 12, 2016 at 3:23 PM, Vladimir Ozerov > > wrote:
>> Hi,
>> 
>> As far as I remember, I created v1.8 for https://apacheignite-fs.readme.io/ 
>>  and made some changes there. These 
>> changes are not relevant anymore, so please go ahead and remove it.
>> However, I am concerned with proposed process. What is the process if I need 
>> to modify existing page? 
>> 
>> Vladimir.
>> 
>> 
>> On Wed, Oct 12, 2016 at 2:57 AM, Denis Magda > > wrote:
>> Guys,
>> 
>> Who exactly created version 1.8 in our documentation? Please remove it and 
>> follow Prachi’s suggestions below.
>> 
>> —
>> Denis
>>  
>>> On Oct 11, 2016, at 4:21 PM, Prachi Garg >> > wrote:
>>> 
>>> Engineers,
>>> 
>>> I see that version 1.8 is created on readme.io . As 
>>> discussed in this email thread below, please DO NOT create any new version 
>>> of the document until the release. If you want to add any new document 
>>> pertaining to the next release, create it within the document for the 
>>> current version and keep the page hidden. 
>>> 
>>> I request you to please move your changes from 1.8 to 1.7, so that I can 
>>> delete 1.8 from readme.io .
>>> 
>>> 
>>> Thanks,
>>> -Prachi
>>> 
>>> 
>>> 
>>> -- Forwarded message --
>>> From: Prachi Garg >
>>> Date: Tue, Sep 6, 2016 at 3:43 PM
>>> Subject: Re: Maintaining documentation consistency on readme.io 
>>> 
>>> To: dev@ignite.apache.org 
>>> 
>>> 
>>> Fixed. 
>>> 
>>> That's why I recommend that from now on we maintain only version at a time 
>>> :)
>>> 
>>> -P
>>> 
>>> On Tue, Sep 6, 2016 at 12:35 PM, Igor Rudyak >> > wrote:
>>> It looks like after copying Ignite-Cassandra module documentation from
>>> version 1.6 to 1.7 it became slightly inconsistent.
>>> 
>>> For example Ganglia dashboard screenshot appeared in "Deployment" (
>>> https://apacheignite.readme.io/docs/aws-infrastructure-deployment#deployment
>>>  
>>> )
>>> while it should be at the end of "Monitoring" section (
>>> https://apacheignite.readme.io/docs/aws-infrastructure-deployment#monitoring
>>>  
>>> 
>>> )
>>> 
>>> Igor
>>> 
>>> 
>>> On Tue, Sep 6, 2016 at 11:50 AM, Prachi Garg >> > wrote:
>>> 
>>> > Fixed. Thanks for pointing it out!
>>> >
>>> > -P
>>> >
>>> > On Sat, Sep 3, 2016 at 9:07 PM, 李玉珏@163 <18624049...@163.com 
>>> > > wrote:
>>> >
>>> > > Prachi:
>>> > >
>>> > > https://apacheignite.readme.io/v1.6/docs/aop-based-grid-enabling 
>>> > > 
>>> > >
>>> > > this doc is missing in the 1.7 version.
>>> > >
>>> > >
>>> > > 在 16/8/26 02:50, Prachi Garg 写道:
>>> > >
>>> > > Right!
>>> > >>
>>> > >>
>>> > >> On Thu, Aug 25, 2016 at 10:28 AM, Dmitriy Setrakyan <
>>> > >> dsetrak...@apache.org >

Re: PR IGNITE-2845 Get operation might ignore entry update from EntryProcessor

[Alexander Fedotov]

Hi,

Looks like that it's actually related to https://issues.apache.org/
jira/browse/IGNITE-3471.
I'll take a look at it. I would suggest, it is by design behavior.
Let me check.

On Tue, Feb 21, 2017 at 8:13 PM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:

> Aleksey,
>
> I am not sure your change is a correct fix. The whole point of
> EntryProcessor is to avoid sending values over the network and send only
> entry processor result, which is typically smaller than the value stored in
> a cache.
>
> Looks like this case is covered by the following ticket:
> https://issues.apache.org/jira/browse/IGNITE-3471. Please cooperate with
> Alexandr to make sure your test is included in his fix.
>
> --AG
>
> 2017-02-21 14:44 GMT+03:00 ALEKSEY KUZNETSOV :
>
> > PR redy, welcome to review : https://github.com/apache/ignite/pull/1557
> >
> > https://issues.apache.org/jira/browse/IGNITE-2845
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
> >
>



-- 
Kind regards,
Alexander.

Re: PR IGNITE-2845 Get operation might ignore entry update from EntryProcessor

[Alexey Goncharuk]

Aleksey,

I am not sure your change is a correct fix. The whole point of
EntryProcessor is to avoid sending values over the network and send only
entry processor result, which is typically smaller than the value stored in
a cache.

Looks like this case is covered by the following ticket:
https://issues.apache.org/jira/browse/IGNITE-3471. Please cooperate with
Alexandr to make sure your test is included in his fix.

--AG

2017-02-21 14:44 GMT+03:00 ALEKSEY KUZNETSOV :

> PR redy, welcome to review : https://github.com/apache/ignite/pull/1557
>
> https://issues.apache.org/jira/browse/IGNITE-2845
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>

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

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

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

[GitHub] ignite pull request #1566: IGNITE-824 Remove GridRandomSelfTest

[SharplEr]

GitHub user SharplEr opened a pull request:

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

IGNITE-824 Remove GridRandomSelfTest



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

$ git pull https://github.com/SharplEr/ignite ignite-824

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

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


commit a25b1daeb2ccb29e7bc4b42712c8ea67a2c68649
Author: Alexander Menshikov 
Date:   2017-02-13T11:55:54Z

Remove GridRandomSelfTest




---
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 #1565: IGNITE-4736 .NET: Remove swap API and cacheMemory...

[ptupitsyn]

Github user ptupitsyn closed the pull request at:

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


---
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-4404 long running test refactoring - how to refactor?

[Yakov Zhdanov]

Konstantin Dudkov, you created ticket some time ago. Can you please clarify?

--Yakov

[jira] [Created] (IGNITE-4737) Update Apache Flink dependencies to the latest version

[Roman Shtykh (JIRA)]

Roman Shtykh created IGNITE-4737:


 Summary: Update Apache Flink dependencies to the latest version
 Key: IGNITE-4737
 URL: https://issues.apache.org/jira/browse/IGNITE-4737
 Project: Ignite
  Issue Type: Task
Reporter: Roman Shtykh
Assignee: Roman Shtykh
Priority: Minor


https://flink.apache.org/downloads.html#maven-dependencies



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

[GitHub] ignite pull request #1565: IGNITE-4736 .NET: Remove swap API and cacheMemory...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-4736 .NET: Remove swap API and cacheMemoryMode



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

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

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

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


commit b46288478519affee1006b8c9575f5dd710f65ab
Author: Pavel Tupitsyn 
Date:   2017-02-21T12:57:58Z

.NET: Remove swap and cacheConfig.MemoryMode

commit a379a93a5315144d3c9e1c84e07516218fc92c71
Author: Pavel Tupitsyn 
Date:   2017-02-21T12:59:37Z

Remove swap space remainings

commit 45633413604c54551efb197af392dd8375508935
Author: Pavel Tupitsyn 
Date:   2017-02-21T13:01:32Z

wip swap

commit 8b7434ec2d788080d87b755a2728735076a295d8
Author: Pavel Tupitsyn 
Date:   2017-02-21T13:05:34Z

cleanup

commit 7ce8232751855abf1eb00eb7ae1b0b02c2ff1019
Author: Pavel Tupitsyn 
Date:   2017-02-21T13:07:03Z

cleanup

commit 8f4c02cbcad2ec10cacf7ac5cb4732615eb23018
Author: Pavel Tupitsyn 
Date:   2017-02-21T13:09:37Z

more config cleanup

commit 375410908668806f5b86640e84799feb4cd91951
Author: Pavel Tupitsyn 
Date:   2017-02-21T13:40:23Z

Disable CachePeekMode.Onheap

commit 3a4364bccc4457efd4acfe20c83dcb06ad9aa804
Author: Pavel Tupitsyn 
Date:   2017-02-21T13:41:17Z

Remove swap peek mode

commit 19c1dd81d9817aeffdfb467c837b1835e0b87116
Author: Pavel Tupitsyn 
Date:   2017-02-21T13:45:51Z

remap peek mode

commit 72fe341d6725c9a318a04e77444983d470e5c882
Author: Pavel Tupitsyn 
Date:   2017-02-21T13:46:15Z

remove swap peek mode

commit 29a71f4c17fafcf195a08dee1fd5af40a253a204
Author: Pavel Tupitsyn 
Date:   2017-02-21T13:51:52Z

wip

commit 39a89c522907b38ed0f1ad5d1b6603ba8bd31627
Author: Pavel Tupitsyn 
Date:   2017-02-21T14:04:12Z

fix store tests




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

[GitHub] ignite pull request #1564: IGNITE-4284

[NSAmelchev]

GitHub user NSAmelchev opened a pull request:

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

IGNITE-4284



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

$ git pull https://github.com/NSAmelchev/ignite IGNITE-4284

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

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


commit bca9756cc4fbe3e89fbc29453d94619d2f90c95b
Author: NSAmelchev 
Date:   2017-02-07T14:04:02Z

Merge remote-tracking branch 'refs/remotes/apache/master'

commit b676ee8bef440447968372ffd56bcf644bfa7175
Author: NSAmelchev 
Date:   2017-01-27T14:56:12Z

Add test

Second client node join with continuous query and peer class loading
enabled

commit 1e1846b681080bf1af29968e552662fbaebb5e66
Author: NSAmelchev 
Date:   2017-01-27T15:04:07Z

Return null for event filter when remote filter factori is null

Fix by returning null for event filter if remote filter factory is null.

commit e90b78aacdc5175a56783c89e60f6e9c5800fd27
Author: NSAmelchev 
Date:   2017-02-20T17:14:48Z

Add Nullable annotation

commit 9266321939112fe39fba237bf7cd6b6d34213a9e
Author: NSAmelchev 
Date:   2017-02-21T10:00:17Z

Add test to suite

commit 01d447c00a44becafffcd5bac8279512a30629e7
Author: NSAmelchev 
Date:   2017-02-21T13:44:07Z

Merge remote-tracking branch 'apache/master' into IGNITE-4284

# Conflicts:
#   
modules/indexing/src/test/java/org/apache/ignite/testsuites/IgniteCacheQuerySelfTestSuite3.java




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

[jira] [Created] (IGNITE-4736) .NET: Remove swap API and cacheMemoryMode

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-4736:
--

 Summary: .NET: Remove swap API and cacheMemoryMode
 Key: IGNITE-4736
 URL: https://issues.apache.org/jira/browse/IGNITE-4736
 Project: Ignite
  Issue Type: Sub-task
  Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.0


Swap space and cacheMemoryMode have been removed in Java. Do the same in .NET



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

[GitHub] ignite pull request #1560: IGNITE-4372 Ids quoting fix

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 #1563: IGNITE-4733

[devozerov]

GitHub user devozerov opened a pull request:

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

IGNITE-4733



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

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

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

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


commit c893da70a9757b16b0799adc8eaa29fa1b03d06e
Author: tledkov-gridgain 
Date:   2016-12-21T11:54:33Z

IGNITE-4399: IGFS: Merged IgfsSecondaryFileSystem and 
IgfsSecondaryFileSystemV2 interfaces. This closes #1346.

commit c5882a85f4e3a1f61723ac54fd92f087684df6da
Author: devozerov 
Date:   2016-12-26T11:15:42Z

Merge branch 'master' into ignite-2.0

commit 7e73d0223a3f09cbe0b7094a2c04bdf9d63ca9be
Author: devozerov 
Date:   2016-12-28T09:54:47Z

Merge branch 'master' into ignite-2.0

commit 7d82d6a06b5e9f1f8cd2909b865e37d46b8da03f
Author: devozerov 
Date:   2016-12-28T09:58:11Z

IGNITE-3875: Introduced separate thread pool for data streamer. This closes 
#1173. This closes #1383.

commit a61b0eaff1817d84c0659e8a7e095f29e22800e1
Author: tledkov-gridgain 
Date:   2016-12-28T11:09:38Z

IGNITE-4405: Hadoop: implemented "readLine" method for HadoopDataInStream 
and HadoopDirectDataInput classes. This closes #1358.

commit 2df39a80d80e2575be61a902ccd48615796fcde9
Author: tledkov-gridgain 
Date:   2016-12-28T13:47:24Z

IGNITE-3961: IGFS: Added IgfsSecondaryFileSystem.affintiy() method. This 
closes #1114. This closes #1252.

commit 2e691d80ea4870c3e7b5b127792b66c920f72c39
Author: tledkov-gridgain 
Date:   2016-12-29T08:00:01Z

IGNITE-4462: IGFS: removed grid name from HadoopIgfsEndpoint. This closes 
#1368.

commit a9b1fc2b3840d47d7c978d9296e8ae6bdeb10be5
Author: tledkov-gridgain 
Date:   2016-12-29T08:07:22Z

IGNITE-4459: Hadoop: weighted planned is default one from now on. This 
closes #1391.

commit 1f743465d6875ef48b1835d03a78a0dbaf339bf6
Author: tledkov-gridgain 
Date:   2016-12-29T08:14:10Z

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

commit 6090ebdfcd0ea3840b0d32cb10197b43615e1e89
Author: devozerov 
Date:   2017-01-05T09:23:06Z

Merge branch 'master' into ignite-2.0

commit 77ca2e636c73e464f833f227c4894df0785ae9e2
Author: devozerov 
Date:   2017-01-16T13:07:49Z

Merge branch 'master' into ignite-2.0

commit d14e0727b3dd61ab5ec2957133d77dbc25e9ba68
Author: tledkov-gridgain 
Date:   2017-01-16T13:36:25Z

IGNITE-4428: Hadoop: moved HadoopMapReducePlanner and dependent classes to 
public space. This closes #1389. This closes #1394.

commit f1365421c299b754a10edf8b6f156aeeb5ff0ce1
Author: tledkov-gridgain 
Date:   2017-01-16T13:57:27Z

IGNITE-4503: Hadoop: added boundary checks to HadoopDirectDataInput. This 
closes # 1416.

commit e08b6ff48916edfab2dbd5d62092be5a1f819a2f
Author: Pavel Tupitsyn 
Date:   2017-01-19T10:34:59Z

Merge branch 'master' into ignite-2.0

commit 43adf8a3f09c6b29fe3e70f62dbc58251d8d7cb9
Author: Ivan Veselovskiy 
Date:   2017-01-19T11:34:23Z

IGNITE-4219: Hadoop: fixed serialization of long strings. This closes #1409.

commit 454b9769e72775c5f6b44a36f0eef84bcce13bd7
Author: devozerov 
Date:   2017-01-19T11:34:43Z

Merge remote-tracking branch 'origin/ignite-2.0' into ignite-2.0

commit 4cd332b781cf700b99402eed2363f988f6403602
Author: Sergey Chugunov 
Date:   2017-01-19T12:05:09Z

IGNITE-4157 Use  discovery custom messages instead of marshaller cache - 
Fixes #1271.

Signed-off-by: Alexey Goncharuk 

commit d0a6c57aa26bca64ef68370c0ebdb5ce45bcc765
Author: Pavel Tupitsyn 
Date:   2017-01-19T14:10:41Z

IGNITE-4441 Define plugin API in .NET

This closes #1362

commit 34a97833905a33bdb31b8e4580a576c2142313a7
Author: Alexey Goncharuk 
Date:   2017-01-19T15:04:23Z

IGNITE-4157 - Added mapping update listener stub

commit e8377167b7b8dd020a93d92c743e4541dcd000ed
Author: Pavel Tupitsyn 
Date:   2017-01-20T10:00:40Z

Merge branch 'master' into ignite-2.0

commit 38cb67d45eb91e20ad4b92a490747534f5e8febb
Author: Pavel Tupitsyn 
Date:   2017-01-20T13:09:57Z

Merge branch 'master' into ignite-2.0

commit 82857d0cb6e2984a5359b822a9c903874414aa67
Author: Pavel Tupitsyn 
Date:   2017-01-23T10:12:12Z

Merge branch 

[GitHub] ignite pull request #1562: IGNITE-4735: Excluded CPP sources.

[isapego]

GitHub user isapego opened a pull request:

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

IGNITE-4735: Excluded CPP sources.



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

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

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

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


commit 1c3e602032df72c844e44cc1eb6224b54d9e8712
Author: Igor Sapego 
Date:   2017-02-21T12:44:30Z

IGNITE-4735: Excluded CPP sources.




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

[jira] [Created] (IGNITE-4735) Some CPP files are missing from source releases.

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-4735:
---

 Summary: Some CPP files are missing from source releases.
 Key: IGNITE-4735
 URL: https://issues.apache.org/jira/browse/IGNITE-4735
 Project: Ignite
  Issue Type: Bug
  Components: build
Affects Versions: 1.8
Reporter: Igor Sapego
Assignee: Igor Sapego
 Fix For: 1.9


Some CPP files missing from the sources release. For example:
- modules/platforms/cpp/common/project/vs/targetver.h
- modules/platforms/cpp/jni/project/vs/targetver.h
- modules/platforms/cpp/core/include/ignite/impl/interop/interop_target.h

It seems that there is issue with files which has "target" in name.



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

[jira] [Created] (IGNITE-4734) Sporadic GridServiceNotFoundException in ServiceExample

[Ksenia Rybakova (JIRA)]

Ksenia Rybakova created IGNITE-4734:
---

 Summary: Sporadic GridServiceNotFoundException in ServiceExample
 Key: IGNITE-4734
 URL: https://issues.apache.org/jira/browse/IGNITE-4734
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 1.7
Reporter: Ksenia Rybakova


Sometimes ServiceExample thows GridServiceNotFoundException
Configs might be different - 1 node/3 nodes, linux/windows

Driver node log:
{noformat}
[10:50:31,428][INFO][main][GridDiscoveryManager] Topology snapshot [ver=2, 
servers=1, clients=1, CPUs=4, heap=2.0GB]
>>>
>>> Starting service proxy example.
>>>
[10:50:31,768][SEVERE][sys-#32%null%][GridTaskWorker] Failed to obtain remote 
job result policy for result from ComputeTask.result(..) method (will fail the 
whole task): GridJobResultImpl [job=C2V2 [c=ServiceProxyCallable [mtdName=put, 
svcName=myNodeSingletonService, ignite=null]], sib=GridJobSiblingImpl 
[sesId=b2c66af5a51-87f5f92a-d9ee-4119-90a5-35659bd7e50d, 
jobId=d2c66af5a51-87f5f92a-d9ee-4119-90a5-35659bd7e50d, 
nodeId=01aea3a3-0981-4760-a26b-732afc4a8a27, isJobDone=false], 
jobCtx=GridJobContextImpl 
[jobId=d2c66af5a51-87f5f92a-d9ee-4119-90a5-35659bd7e50d, timeoutObj=null, 
attrs={}], node=TcpDiscoveryNode [id=01aea3a3-0981-4760-a26b-732afc4a8a27, 
addrs=[127.0.0.1, 172.25.2.17], sockAddrs=[/172.25.2.17:47500, 
/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
lastExchangeTime=1487663430926, loc=false, ver=1.7.8#20170220-sha1:6112bce9, 
isClient=false], ex=class o.a.i.IgniteException: Service not found: 
myNodeSingletonService, hasRes=true, isCancelled=false, isOccupied=true]
class org.apache.ignite.IgniteException: Remote job threw user exception 
(override or implement ComputeTask.result(..) method if you would like to have 
automatic failover for this exception).
at 
org.apache.ignite.compute.ComputeTaskAdapter.result(ComputeTaskAdapter.java:101)
at 
org.apache.ignite.internal.processors.task.GridTaskWorker$5.apply(GridTaskWorker.java:1031)
at 
org.apache.ignite.internal.processors.task.GridTaskWorker$5.apply(GridTaskWorker.java:1024)
at 
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6596)
at 
org.apache.ignite.internal.processors.task.GridTaskWorker.result(GridTaskWorker.java:1024)
at 
org.apache.ignite.internal.processors.task.GridTaskWorker.onResponse(GridTaskWorker.java:842)
at 
org.apache.ignite.internal.processors.task.GridTaskProcessor.processJobExecuteResponse(GridTaskProcessor.java:996)
at 
org.apache.ignite.internal.processors.task.GridTaskProcessor$JobMessageListener.onMessage(GridTaskProcessor.java:1221)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1082)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:710)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:102)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:673)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: class org.apache.ignite.IgniteException: Service not found: 
myNodeSingletonService
at 
org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2V2.execute(GridClosureProcessor.java:2059)
at 
org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:560)
at 
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6564)
at 
org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:554)
at 
org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:483)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at 
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1180)
at 
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1894)
... 7 more
Caused by: class 
org.apache.ignite.internal.processors.service.GridServiceNotFoundException: 
Service not found: myNodeSingletonService
at 
org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.call(GridServiceProxy.java:397)
at 
org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2V2.execute(GridClosureProcessor.java:2056)
... 14 more
Map service size: 10
>>>
>>> Starting service injection example.
>>>
[10:50:31,905][INFO][main][GridDeploymentLocalStore] Class locally 

IGNITE-4404 long running test refactoring - how to refactor?

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

Hello, community. Ticket description:

in testTransform

final int THREADS = 5;
final int ITERATIONS_PER_THREAD = 10_000;

So, what should I change?
Other methods have

final int THREADS = 5;
final int ITERATIONS_PER_THREAD = iterations();

where iterations() {return 10_000;}

Should I use iterations() and create same method for threads? Or may be
replace all local finals to class finals?

Should I do something else? Couse the only way to make test shorter is to
reduce number of iterations, but purpose of this test is long concurrent
actions.

PR IGNITE-2845 Get operation might ignore entry update from EntryProcessor

[ALEKSEY KUZNETSOV]

PR redy, welcome to review : https://github.com/apache/ignite/pull/1557

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

*Best Regards,*

*Kuznetsov Aleksey*

[GitHub] ignite pull request #1561: IGNITE-4729 Async operation support in platform p...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-4729 Async operation support in platform plugins



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

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

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

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


commit e9b63445fce527baf5835227fd1414a8e2f7fbd9
Author: Pavel Tupitsyn 
Date:   2017-02-21T11:34:26Z

IGNITE-4729 Async operation support in platform plugins




---
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 #1560: IGNITE-4372 Ids quoting fix

[alexpaschenko]

GitHub user alexpaschenko opened a pull request:

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

IGNITE-4372 Ids quoting fix



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

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

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

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


commit 14290d3fe44af7e2269d42361f2bb1207b0ee8c3
Author: Alexander Paschenko 
Date:   2017-02-21T11:00:45Z

IGNITE-4372 Ids quoting fix




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

[jira] [Created] (IGNITE-4732) Invalid ids quoting logic in DML and GridSqlFunction

[Alexander Paschenko (JIRA)]

Alexander Paschenko created IGNITE-4732:
---

 Summary: Invalid ids quoting logic in DML and GridSqlFunction
 Key: IGNITE-4732
 URL: https://issues.apache.org/jira/browse/IGNITE-4732
 Project: Ignite
  Issue Type: Bug
  Components: SQL
Affects Versions: 1.9
Reporter: Alexander Paschenko
Assignee: Alexander Paschenko
 Fix For: 1.9






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

Re: Major release 2.0 and compilation

[Taras Ledkov]

I've updated the issue: 
https://issues.apache.org/jira/browse/IGNITE-3469 with two lists of 
deprecated API: public and private.


Please take a look. I would create sub tasks for each to make review 
simpler then one huge patch that contains the whole refactoring.


The list of the deprecated public class / methods / properties:

- two methods IgniteCluster.mapKeyToNode - the removing is simple 
because its are used rare;

- IgniteCache.randomEntry - the removing is simple because it is used rare;
- The system flags:
- IGNITE_BINARY_SORT_OBJECT_FIELDS;
- IGNITE_BINARY_DONT_WRAP_TREE_STRUCTURES;
- IGNITE_MIN_BUFFERED_COMMUNICATION_MSG_CNT - not used in the 
projects now.

- CacheTypeMetadata;
- Classes related with AffinityNodeHashResolver;
- Backup filters for affinity functions;
- RandomEvictionPolicy;
- ContinuousQuery.setRemoteFilter;
- CacheStore.sessionEnd;
- CacheAbstractJdbcStore.translateFields;
- CacheJdbcPojoStoreFactory.setDataSource;
- CacheConfiguration properties: transactionManagerLookupClassName and 
{rebalanceThreadPoolSize}};

- ConnectorConfiguration.sslContextFactory property;
- FileSystemConfiguration properties:
- fragmentizerLocalWritesRatio;
- trashPurgeTimeout;
- dualModePutExecutorService;
- dualModePutExecutorServiceShutdown;
- dualModeMaxPendingPutsSize;
- IgniteConfiguration properties:
- nodeId;
- DFLT_PUBLIC_KEEP_ALIVE_TIME;
- DFLT_PUBLIC_THREADPOOL_QUEUE_CAP;
- DFLT_SYSTEM_MAX_THREAD_CNT;
- DFLT_SYSTEM_KEEP_ALIVE_TIME;
- DFLT_UTILITY_KEEP_ALIVE_TIME;
- DFLT_SYSTEM_THREADPOOL_QUEUE_CAP;
- TransactionConfiguration properties:
- txSerializableEnabled;
- txManagerLookupClassName;
- Several methods at the IgfsPath class: empty constructor, root() and 
isSame methods;

- IgniteSpiContext: methods addMessageListener, removeMessageListener;
- TcpCommunicationSpi properties:
- connectionBufferSize;
- connectionBufferFlushFrequency;
- minimumBufferedMessageCount;
- StreamTupleExtractor class and relations;
- ignite-hadoop: Several constructors of the 
IgniteHadoopIgfsSecondaryFileSystem;

- ignite-yarn: ApplicationMaster.getContainers().

The list of the deprecated private class / methods / properties:

- Classes are retated to the GridSslContextFactory;
- JdbcConnection related classes;
- GridCacheUtils.cheatCache;
- GridCacheCommittedTxInfo;
- GridDistributedTxFinishRequest: syncCommit, syncRollback;
- GridDhtPartitionDemander: demandLock, dmIdx, worker, SupplyMessage, 
DemandWorker;

- One of the constructors of the GridDhtPartitionFullMap;
- GridDhtPartitionMap;
- GridDhtPartitionSupplier old listeners & old demand message;
- AffinityTask.affinityKey()
- GridQueryRequest;
- One of the constructors of GridLeanSet;
- Several methods at the IgniteUtils;
- Several methods at the GridFunc;
- GridTupleV;
- PlatformDotNetBinaryTypeConfiguration.isKeepDeserialized();
- ServerImpl.RingMessageWorker.processNodeAddedMessage;
- TcpDiscoverySpi.versionCheckFailed;

On 08.12.2016 1:04, Denis Magda wrote:

I would remove as much as possible and prepare a migration guide as Sergey K. 
suggests below.

In any case, we will stick to the flexible approach. As the next step I would 
split all the existed APIs in 2 groups. The first group will be for the APIs 
that will be deleted and we will provide instructions in the migration guide on 
how to migrate from them. The second group will be for those that will be left.

Actually, there is an already existed ticket for this
https://issues.apache.org/jira/browse/IGNITE-3469 


—
Denis


On Dec 7, 2016, at 10:12 AM, Sergey Kozlov  wrote:

I would remind that Apache Ignite 1.0.0 has been released 20 months ago and
probably 2.0 will be rolled out close to the second anniversary of initial
release. It's right time to remove deprecated API and provide for users the
clear ways for migration 1.x to 2.0.

I think we could create a wiki page for users who can recompile their
applications, list all deprecated API calls and provide migration's
tips/tricks from deprecated features to new ones (something like the table
with columns "Deprecated API call for 1.x", "API call for 2.0/workaround").



On Wed, Dec 7, 2016 at 11:36 AM, Yakov Zhdanov  wrote:


Agree with Vladimir that we should use flexible approach and should avoid
any possible harm here, but cleaning out most of deprecations is the way to
go, IMO. There are about 90 occurrences of "deprecated" in the project and
most of them are not very hard to remove. Moreover, we have, for example,
setRemoteFilter(CacheEntryEventSerializableFilter). Using this
method
is error prone. We should remove it so none can use it.

Cleaning up and renovating are good. This allows us to see what can be done
better and also encourages users to move forward.

--Yakov

2016-12-07 15:22 GMT+07:00 Vladimir Ozerov :


Igniters,

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

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

[GitHub] ignite pull request #1559: IGNITE-4712 Memory leaks in PageMemory

[gvvinblade]

GitHub user gvvinblade opened a pull request:

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

IGNITE-4712 Memory leaks in PageMemory



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

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

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

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


commit 3c9e3786a21ec7c8919de9c29bc04d2e3561846c
Author: Igor Seliverstov 
Date:   2017-02-15T10:41:08Z

IGNITE-4694 Add tests to check there are no memory leaks in PageMemory

commit 8e12097f9094d7f155135ee2f4c9c33f5f7af9aa
Author: sboikov 
Date:   2017-02-15T12:08:14Z

ignite-4694 review

commit e70d990f14288cfc8fe211fa25631016d5708144
Author: Igor Seliverstov 
Date:   2017-02-15T15:04:38Z

IGNITE-4694 Add tests to check there are no memory leaks in PageMemory

commit 84c03e0c522abc90b2d91e514138eac08388abd2
Author: Igor Seliverstov 
Date:   2017-02-16T10:41:51Z

IGNITE-4694 Add tests to check there are no memory leaks in PageMemory 
(pending)

commit e259b7a2032de9ec1334668e10f92fbae9e5c096
Author: Igor Seliverstov 
Date:   2017-02-20T10:40:05Z

IGNITE-4712 Memory leaks in PageMemory

commit fa395addf03376423b9aeb15dd74a7a9969cb851
Author: Igor Seliverstov 
Date:   2017-02-20T10:43:36Z

IGNITE-4712 Memory leaks in PageMemory

commit be241d9789392f13c4951e9588c85357cd79192f
Author: Igor Seliverstov 
Date:   2017-02-20T13:19:00Z

IGNITE-4712 Memory leaks in PageMemory

commit 4376f82d13ef4d08c4eb8d9b6e3f19cba9d9ce1c
Author: Igor Seliverstov 
Date:   2017-02-20T13:40:25Z

IGNITE-4712 Memory leaks in PageMemory

commit 95faf450cbbf6be4887965209bec3ae0244bcdd9
Author: Igor Seliverstov 
Date:   2017-02-20T15:11:34Z

IGNITE-4712 Memory leaks in PageMemory

commit bfb0021b9fbda0ca9fde83ba5513ed3eb32f3703
Author: Igor Seliverstov 
Date:   2017-02-20T15:25:07Z

IGNITE-4712 Memory leaks in PageMemory

commit 4ae7d7177b1e55c31579c4691514655eeadb833f
Author: Igor Seliverstov 
Date:   2017-02-20T15:31:15Z

IGNITE-4712 Memory leaks in PageMemory

commit 5e4e991360c2f2917ec22128e40a353c13db8285
Author: Igor Seliverstov 
Date:   2017-02-21T08:49:35Z

IGNITE-4694 Add tests to check there are no memory leaks in PageMemory




---
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 #1558: Ignite-602

[SomeFire]

GitHub user SomeFire opened a pull request:

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

Ignite-602

Test fixed and extended. Added notes to GridToStringBuilder about infinite 
looping in additional values.

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

$ git pull https://github.com/SomeFire/ignite ignite-602

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

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


commit 3f4ebad9bd1b1dc94cd49dfe349e373b959b8803
Author: Dmitrii Ryabov 
Date:   2017-02-20T15:00:11Z

Test testToStringCheckAdvancedRecursionPrevention fixed.
Added notes to GridToStringBuilder about infinite looping in additional 
values.

commit 7ff77dc63806c471003dfb50c11548f18ab87b57
Author: Dmitrii Ryabov 
Date:   2017-02-20T15:28:47Z

Test testToStringCheckAdvancedRecursionPrevention fixed.
Added notes to GridToStringBuilder about infinite looping in additional 
values.

commit eb88e5ceedd73acbb054eb9f388f1fd44e68dd73
Author: Dmitrii Ryabov 
Date:   2017-02-21T07:40:02Z

Merge branch 'master' into ignite-602




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

[jira] [Created] (IGNITE-4731) Web Console: Revise loaders

[Vica Abramova (JIRA)]

Vica Abramova created IGNITE-4731:
-

 Summary: Web Console: Revise loaders
 Key: IGNITE-4731
 URL: https://issues.apache.org/jira/browse/IGNITE-4731
 Project: Ignite
  Issue Type: Task
  Components: UI, wizards
Reporter: Vica Abramova


Revise two types of loaders (big and small):
- check the color of big
- add loader to the Queries screen (on execute action)
- check the color of Refresh buttons with animated small loaders




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

[GitHub] ignite pull request #1557: IGNITE-2845 Get operation might ignore entry upda...

[voipp]

GitHub user voipp opened a pull request:

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

IGNITE-2845 Get operation might ignore entry update from EntryProcessor.



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

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

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

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


commit e27b838b0d90dfc8479af56b7a315d84f2b684e2
Author: voipp 
Date:   2017-02-20T14:15:10Z

IGNITE-2845 Get operation might ignore entry update from EntryProcessor.




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

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

Hi Valentin!

I compare speed of different methods how to get byte from string and push
it to outputstream.

Third method is the fastest.

Ok, I'm creating a benchmark for BinaryWriterExImpl#doWriteString method,
and making the change described in the ticket.

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

Vadim

2017-02-21 1:06 GMT+03:00 Valentin Kulichenko :

> Hi Vadim,
>
> I'm not sure I understand your benchmarks and how they verify the
> optimization discussed here. Basically, here is what needs to be done:
>
> 1. Create a benchmark for BinaryWriterExImpl#doWriteString method.
> 2. Run the benchmark with current implementation.
> 3. Make the change described in the ticket.
> 4. Run the benchmark with these changes.
> 5. Compare results.
>
> Makes sense? Let me know if anything is unclear.
>
> -Val
>
> On Mon, Feb 20, 2017 at 8:51 AM, Вадим Опольский 
> wrote:
>
>> Hello everybody!
>>
>> https://issues.apache.org/jira/browse/IGNITE-13
>>
>> Valentin, I just have finished benchmark (with JMH) -
>> https://github.com/javaller/MyBenchmark.git
>>
>> It collect data about time working of serialization.
>>
>> For instance - https://github.com/javaller/My
>> Benchmark/blob/master/out200217.txt
>>
>> To start it you have to do next:
>>
>> 1) clone it - git colne https://github.com/javaller/MyBenchmark.git
>>
>> 2) install it - mvn install
>>
>> 3) run benchmarks -  java -Xms1024m -Xmx4096m -jar target\benchmarks.jar
>>
>> Vadim Opolski
>>
>>
>>
>>
>>
>> 2017-02-15 0:52 GMT+03:00 Valentin Kulichenko <
>> valentin.kuliche...@gmail.com>:
>>
>>> Vladimir,
>>>
>>> I think we misunderstood each other. My understanding of this
>>> optimization is the following.
>>>
>>> Currently string serialization is done in two steps (see
>>> BinaryWriterExImpl#doWriteString):
>>>
>>> strArr = BinaryUtils.strToUtf8Bytes(val); // Encode string into byte
>>> array.
>>> out.writeByteArray(strArr);  // Write byte array
>>> into stream.
>>>
>>> What this ticket suggests is to write directly into stream while string
>>> is encoded, without intermediate array. This both reduces memory
>>> consumption and eliminates array copy step.
>>>
>>> I updated the ticket and added this explanation there.
>>>
>>> Vadim, can you create a micro benchmark and check if it gives any
>>> improvement?
>>>
>>> -Val
>>>
>>> On Sun, Feb 12, 2017 at 10:38 PM, Vladimir Ozerov 
>>> wrote:
>>>
 Hi,

 It is hard to say whether it makes sense or not. No doubt, it could
 speed up marshalling process at the cost of 2x memory required for strings.
 From my previous experience with marshalling micro-optimizations, we will
 hardly ever notice speedup in distributed environment.

 But, there is another sied - it could speedup our queries, because we
 will not have to unmarshal string on every field access. So I would try to
 make this optimization optional and then measure query performance with
 classes having lots of strings. It could give us interesting results.

 On Mon, Feb 13, 2017 at 5:37 AM, Valentin Kulichenko <
 valentin.kuliche...@gmail.com> wrote:

> Vladimir,
>
> Can you please take a look and provide your thoughts? Can this be
> applied to binary marshaller? From what I recall, it serializes string a
> bit differently from optimized marshaller, so I'm not sure.
>
> -Val
>
> On Fri, Feb 10, 2017 at 5:16 PM, Dmitriy Setrakyan <
> dsetrak...@apache.org> wrote:
>
>> On Thu, Feb 9, 2017 at 11:26 PM, Valentin Kulichenko <
>> valentin.kuliche...@gmail.com> wrote:
>>
>> > Hi Vadim,
>> >
>> > I don't think it makes much sense to invest into
>> OptimizedMarshaller.
>> > However, I would check if this optimization is applicable to
>> > BinaryMarshaller, and if yes, implement it.
>> >
>>
>> Val, in this case can you please update the ticket?
>>
>>
>> >
>> > -Val
>> >
>> > On Thu, Feb 9, 2017 at 11:05 PM, Вадим Опольский <
>> vaopols...@gmail.com>
>> > wrote:
>> >
>> > > Dear sirs!
>> > >
>> > > I want to resolve issue IGNITE-13 -
>> > > https://issues.apache.org/jira/browse/IGNITE-13
>> > >
>> > > Is it actual?
>> > >
>> > > Vadim Opolski
>> > >
>> >
>>
>
>

>>>
>>
>