Re: IGNITE-13

[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/MyBenchmark/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
> > >
> >
>


>>>
>>
>

Re: Entry filter in IgniteCache#loadCache

[Dmitriy Setrakyan]

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?


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


>
> 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 #1556: IGNITE-4106: SQL: parallelize sql queries over ca...

[AMashenkov]

GitHub user AMashenkov opened a pull request:

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

IGNITE-4106: SQL: parallelize sql queries over cache local partitions

Merged with IGNITE-1.9.

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

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

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

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


commit 608032b900a51a7fba99e383c0fe0d8a37558cbb
Author: AMRepo 
Date:   2017-02-20T18:24:29Z

Implemented.

commit b7c5ae313fa7c4cc6765e2f3ce8eb30d46c93f10
Author: AMRepo 
Date:   2017-02-20T19:53:33Z

Merge remote-tracking branch 'apache/ignite-1.9' into ignite-4106-1.9

# Conflicts:
#   
modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/IgniteH2Indexing.java
#   
modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/opt/GridH2IndexBase.java
#   
modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/twostep/GridMapQueryExecutor.java
#   
modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/twostep/GridReduceQueryExecutor.java
#   
modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/twostep/msg/GridH2QueryRequest.java
#   
modules/indexing/src/test/java/org/apache/ignite/internal/processors/query/IgniteSqlSplitterSelfTest.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.
---

[GitHub] ignite pull request #1278: IGNITE-4106: SQL: parallelize sql queries over ca...

[AMashenkov]

Github user AMashenkov closed the pull request at:

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


---
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-4730) .NET: Propagate IgniteConfiguration.OdbcConfiguration

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-4730:
--

 Summary: .NET: Propagate IgniteConfiguration.OdbcConfiguration
 Key: IGNITE-4730
 URL: https://issues.apache.org/jira/browse/IGNITE-4730
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn
 Fix For: 2.1


ODBC can be enabled via {{IgniteConfiguration.odbcConfiguration}} in Java. 
Propagate this property to .NET.

https://apacheignite.readme.io/docs/odbc-driver



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

Clean sitemap.xml for the website

[Mauricio Stekl]

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





cleaned-up-sitemap.patch.bz2
Description: BZip2 compressed data

Re: IGNITE-13

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

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/MyBenchmark/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 :

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

>>>
>>>
>>
>

[jira] [Created] (IGNITE-4729) Async operation support in platform plugins

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-4729:
--

 Summary: Async operation support in platform plugins
 Key: IGNITE-4729
 URL: https://issues.apache.org/jira/browse/IGNITE-4729
 Project: Ignite
  Issue Type: Sub-task
  Components: platforms
Reporter: Pavel Tupitsyn
 Fix For: 2.0


Expose a set of async operations on {{IPlatformTarget}}



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

general question

[ALEKSEY KUZNETSOV]

Hi! Why local deployment SPI is ignored, if peer class loading is disabled,
and local deployment spi is enabled ?
-- 

*Best Regards,*

*Kuznetsov Aleksey*

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

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

Do we still need this test? Can I remove it?

[jira] [Created] (IGNITE-4728) Web Console: Remember the screen from which user has left the previous session.

[Vica Abramova (JIRA)]

Vica Abramova created IGNITE-4728:
-

 Summary: Web Console: Remember the screen from which user has left 
the previous session.
 Key: IGNITE-4728
 URL: https://issues.apache.org/jira/browse/IGNITE-4728
 Project: Ignite
  Issue Type: Task
  Components: UI, wizards
Reporter: Vica Abramova






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

[jira] [Created] (IGNITE-4727) Web Console: Fix the position of tooltips in modal windows

[Vica Abramova (JIRA)]

Vica Abramova created IGNITE-4727:
-

 Summary: Web Console: Fix the position of tooltips in modal windows
 Key: IGNITE-4727
 URL: https://issues.apache.org/jira/browse/IGNITE-4727
 Project: Ignite
  Issue Type: Bug
  Components: UI, wizards
Reporter: Vica Abramova


Tooltips (in modal windows) should not go beyond the modal windows.




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

Re: IGNITE-1948 ClusterTopologyCheckedException can return null for retryReadyFuture()

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

Alexey,

I'm ready to make some conclusions. You can see result immediately here:
PR:  https://github.com/apache/ignite/pull/1537/files
CI Tests:
http://ci.ignite.apache.org/project.html?projectId=IgniteTests=projectOverview_IgniteTests=pull/1537/head

I fixed only "ClusterTopologyCheckedException", and didn't touched
"ClusterTopologyException". "ClusterTopologyException" has a same problem
like "ClusterTopologyCheckedException", but even now changes is huge (80
files). So if you think fixing of "ClusterTopologyException" is necessary,
you could add different issue in JIRA (or I can do that). And I will fix it
in future. I can't implement your idea about using Runtime exception,
because right now a lot of logic tied to the fact that this is
"IgniteCheckedException". I real tried to mix it but I couldn't make it
work.

So before my changes we have 3 affected classes:
1. "ClusterTopologyCheckedException".
2. "ClusterTopologyServerNotFoundException".
3. "ClusterGroupEmptyCheckedException".

Now we there are 5 affected classes:

"ClusterTopologyCheckedException" split into 2 classes:
1. "ClusterTopologyCheckedException" (with future).
2. "ClusterTopologyLocalException" (without future, and it's parent for
"ClusterTopologyCheckedException").

"ClusterTopologyServerNotFoundException" rename to
3. "ClusterTopologyServerNotFoundLocalException" (For consistency of names,
I didn't find any cases where "ClusterTopologyServerNotFoundException" need
his future).

"ClusterGroupEmptyCheckedException" split into 2 classes:
4. "ClusterGroupEmptyCheckedException".
5. "ClusterGroupEmptyLocalException".

Also in code "ready future" is using for waiting, and don't using for get
real value (just look at code, all values just ignored). In fact "ready
future" has type "IgniteFuture". It suggests that result doesn't matter.

2017-02-10 11:06 GMT+03:00 Alexey Goncharuk :

> Alexander,
>
> I do not see why you would need to overwrite the cause field.
>
> What I meant in the previous email is that instead of setting a retry
> ready future in the checked exception, you would set a correct affinity
> topology version here. Then, during a construction of CacheException
> (unchecked, which is guaranteed to be thrown locally and will not be
> serialized), you would create the retry ready future based on the topology
> version set.
>
> Hope this helps,
> AG
>
> 2017-02-07 17:18 GMT+03:00 Александр Меньшиков :
>
>> Alexey, I ran into some difficulties.
>>
>> Look at the method: GridNearTxFinishFuture.CheckBa
>> ckupMiniFuture#onDhtFinishResponse(GridDhtTxFinishResponse res)
>>
>> *Throwable err* = res.checkCommittedError();
>>
>> if (*err* != null) {
>> if (*err* instanceof IgniteCheckedException) {
>> *ClusterTopologyCheckedException cause* =
>> ((IgniteCheckedException)*err*).
>> *getCause(ClusterTopologyCheckedException.class)*;
>>
>> if (*cause* != null)
>> *cause.retryReadyFuture(*cctx.ne
>> xtAffinityReadyFuture(tx.topologyVersion()));
>> *   //^_Here update the readyFut in
>> some first "cause". *
>> }
>>
>> onDone(*err*);
>> }
>>
>>
>> So I can't rewrite "cause" field in exception without reflection. It
>> means if I try to use two exception: one with "readyFut" and second without
>> "readyFut", I see no way to do it in this place.
>>
>> Perhaps I misunderstood your original idea. Or maybe this code some kind
>> of a crutch and should be removed. What do you think?
>>
>> 2017-01-30 16:54 GMT+03:00 Alexey Goncharuk :
>>
>>> In the example above there is no point of setting the retry future in the
>>> exception because it will be serialized and sent to a remote node.
>>>
>>> I see the only possible way to ensure this: make this be verified at
>>> compile time. This looks like a big change, but the draft may look like
>>> so:
>>> 1) Introduce new exception type, like CacheTopology*Checked*Exception
>>> which
>>> *must* take the minimum topology version to wait for
>>> 2) In all cases when a cache operation fails because of topology change,
>>> provide the appropriate exception
>>> 3) When CacheTopologyException is being constructed, create a
>>> corresponding
>>> local future based on wait version and throw the exception.
>>>
>>> Even though this still does not give us 100% guarantee that we did not
>>> miss
>>> anything, it should cover a lot more cases than now.
>>>
>>> 2017-01-30 14:20 GMT+03:00 Александр Меньшиков :
>>>
>>> > Alexey,
>>> >
>>> > For GridCacheIoManager#sendNoRetry it's not necessary because exception
>>> > will be ignored (or will cast to String). Perhaps my message was
>>> unclear.
>>> > I try to say that three methods can throw
>>> "ClusterTopologyCheckedException"
>>> > without any problem.
>>> >
>>> > 

Re: Locking of partition with affinityRun/affinityCall

[Taras Ledkov]

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: Entry filter in IgniteCache#loadCache

[Vladimir Ozerov]

+1

On Sat, Feb 18, 2017 at 11: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.
>- In case filtering has to be dynamic (i.e. use does wants to provide a
>predicate as an argument), generic arguments can be used.
>
> 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.
>
> Thoughts?
>
> -Val
>

[GitHub] ignite pull request #521: comm balance debug

[yzhdanov]

Github user yzhdanov closed the pull request at:

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


---
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-4726) SQL: benchmark DML operations

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4726:
---

 Summary: SQL: benchmark DML operations
 Key: IGNITE-4726
 URL: https://issues.apache.org/jira/browse/IGNITE-4726
 Project: Ignite
  Issue Type: Task
  Components: SQL
Reporter: Vladimir Ozerov
 Fix For: 2.0


We need to create benchmarks for DML operations similar to our cache benchmarks 
and compare common cases. Results of cache API benchmarks can be used as 
baseline for us.

Preliminray list of benchmarks:
1) INSERT + DELETE (vs {{IgniteCache.put}} + {{IgniteCache.remove}})
2) Simple MERGE (vs {{IgniteCache.put}})
3) Simple UPDATE (vs {{IgniteCache.invoke}})



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

[GitHub] ignite pull request #1447: IGNITE-4157 mapping updates notification hook

[sergey-chugunov-1985]

Github user sergey-chugunov-1985 closed the pull request at:

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


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

Re: Apache Ignite 1.9

[Anton Vinogradov]

Igniters,

Code freeze date changed to Feb 20 19-00 MSK.
Since that time, each fix should be allowed at this thread before push.

On Mon, Feb 20, 2017 at 1:50 PM, Vladimir Ozerov 
wrote:

> Igniters,
>
> IGNITE-4169 [1] (streaming in DML) has been merged to 1.9 branch.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-4169
>
> On Fri, Feb 17, 2017 at 4:01 PM, Anton Vinogradov <
> avinogra...@gridgain.com>
> wrote:
>
> > https://issues.apache.org/jira/browse/IGNITE-3862
> > already at 1.9, fixed  "fixVersion".
> >
> > On Fri, Feb 17, 2017 at 2:40 PM, michael.griggs <
> > michael.gri...@gridgain.com
> > > wrote:
> >
> > > Denis/all, can we also get [1] in Ignite 1.9 ?
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-3862
> > >
> > >
> > >
> > > --
> > > View this message in context: http://apache-ignite-
> > > developers.2346864.n4.nabble.com/Apache-Ignite-1-9-tp14170p14752.html
> > > Sent from the Apache Ignite Developers mailing list archive at
> > Nabble.com.
> > >
> >
>

[GitHub] ignite pull request #1554: IGNITE-4409 UUID literals handling.

[alexpaschenko]

GitHub user alexpaschenko opened a pull request:

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

IGNITE-4409 UUID literals handling.



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

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

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

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


commit 3fd684390016483cd67af5f3b05b477b8fdf540a
Author: Alexander Paschenko 
Date:   2017-02-20T11:07:12Z

IGNITE-4409 UUID literals handling.




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

[Vladimir Ozerov]

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: Apache Ignite 1.9

[Vladimir Ozerov]

Igniters,

IGNITE-4169 [1] (streaming in DML) has been merged to 1.9 branch.

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

On Fri, Feb 17, 2017 at 4:01 PM, Anton Vinogradov 
wrote:

> https://issues.apache.org/jira/browse/IGNITE-3862
> already at 1.9, fixed  "fixVersion".
>
> On Fri, Feb 17, 2017 at 2:40 PM, michael.griggs <
> michael.gri...@gridgain.com
> > wrote:
>
> > Denis/all, can we also get [1] in Ignite 1.9 ?
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-3862
> >
> >
> >
> > --
> > View this message in context: http://apache-ignite-
> > developers.2346864.n4.nabble.com/Apache-Ignite-1-9-tp14170p14752.html
> > Sent from the Apache Ignite Developers mailing list archive at
> Nabble.com.
> >
>

[jira] [Created] (IGNITE-4725) Document streaming mode for JDBC driver

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4725:
---

 Summary: Document streaming mode for JDBC driver
 Key: IGNITE-4725
 URL: https://issues.apache.org/jira/browse/IGNITE-4725
 Project: Ignite
  Issue Type: Task
  Components: documentation, SQL
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 1.9


SQL streaming was added to {{AI 1.9}}. We need to document it.



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

Re: Ignite 1.8 c++ Platform installation issue

[Igor Sapego]

Well, this is another issue. It has been fixed already, but still affects
1.8.0 source release.

As a workaround for now you can use sources from Git repository 1.8.0 tag
[1], or you can
only get missing apache-ignite-1.8.0-src/modules/platforms/cpp/core/include/
ignite/impl/interop/interop_target.h
file from there and put it in your sources.

[1] - https://github.com/apache/ignite/releases/tag/1.8.0

Best Regards,
Igor

On Mon, Feb 20, 2017 at 1:33 PM, Shashank Gandham  wrote:

> Hi,
>
> If I ignore that and continue with the process of installation with 'make'
> command, here is the error I get.
>
> make[3]: Entering directory
> './apache-ignite-1.8.0-src/modules/platforms/cpp/core/include'
> make[3]: *** No rule to make target 'ignite/impl/interop/interop_
> target.h',
> needed by 'all-am'.  Stop.
> make[3]: Leaving directory
> './apache-ignite-1.8.0-src/modules/platforms/cpp/core/include'
> Makefile:697: recipe for target 'all-recursive' failed
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory
> './apache-ignite-1.8.0-src/modules/platforms/cpp/core'
> Makefile:426: recipe for target 'all-recursive' failed
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory './apache-ignite-1.8.0-src/
> modules/platforms/cpp'
> Makefile:358: recipe for target 'all' failed
> make: *** [all] Error 2
>
> Regards,
> Shashank
>
> On Mon, Feb 20, 2017 at 3:39 PM, Igor Sapego  wrote:
>
> > Hi,
> >
> > This is not an error. It comes from the Automake buildsystem considers
> > files named "core" to be a coredumps and tries to remove them. Ignite C++
> > has library named "core" with corresponding directory.
> >
> > Shortly speaking, just ignore this message.
> >
> > Best Regards,
> > Igor
> >
> > On Sun, Feb 19, 2017 at 12:45 PM, Shashank Gandham <
> > shashankgand...@gmail.com> wrote:
> >
> > > The ./configure command produces the following error:
> > >
> > > configure: creating ./config.status
> > > config.status: creating Makefile
> > > config.status: creating core-test/include/Makefile
> > > config.status: creating core-test/Makefile
> > > config.status: creating common/os/linux/include/Makefile
> > > config.status: creating common/include/Makefile
> > > config.status: creating common/Makefile
> > > config.status: creating binary/include/Makefile
> > > config.status: creating binary/Makefile
> > > config.status: creating odbc/include/Makefile
> > > config.status: creating odbc/Makefile
> > > config.status: creating odbc-test/include/Makefile
> > > config.status: creating odbc-test/Makefile
> > > config.status: creating core/include/Makefile
> > > config.status: creating core/Makefile
> > > config.status: creating core/ignite.pc
> > > config.status: creating jni/include/Makefile
> > > config.status: creating jni/Makefile
> > > config.status: creating ignite/Makefile
> > > config.status: creating config.h
> > > config.status: config.h is unchanged
> > > config.status: executing depfiles commands
> > > config.status: executing libtool commands
> > > rm: cannot remove 'core': Is a directory
> > >
> > > Does this need some fixing, or am I missing some steps?
> > >
> >
>

Re: Ignite 1.8 c++ Platform installation issue

[Shashank Gandham]

Hi,

If I ignore that and continue with the process of installation with 'make'
command, here is the error I get.

make[3]: Entering directory
'./apache-ignite-1.8.0-src/modules/platforms/cpp/core/include'
make[3]: *** No rule to make target 'ignite/impl/interop/interop_target.h',
needed by 'all-am'.  Stop.
make[3]: Leaving directory
'./apache-ignite-1.8.0-src/modules/platforms/cpp/core/include'
Makefile:697: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
'./apache-ignite-1.8.0-src/modules/platforms/cpp/core'
Makefile:426: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory './apache-ignite-1.8.0-src/modules/platforms/cpp'
Makefile:358: recipe for target 'all' failed
make: *** [all] Error 2

Regards,
Shashank

On Mon, Feb 20, 2017 at 3:39 PM, Igor Sapego  wrote:

> Hi,
>
> This is not an error. It comes from the Automake buildsystem considers
> files named "core" to be a coredumps and tries to remove them. Ignite C++
> has library named "core" with corresponding directory.
>
> Shortly speaking, just ignore this message.
>
> Best Regards,
> Igor
>
> On Sun, Feb 19, 2017 at 12:45 PM, Shashank Gandham <
> shashankgand...@gmail.com> wrote:
>
> > The ./configure command produces the following error:
> >
> > configure: creating ./config.status
> > config.status: creating Makefile
> > config.status: creating core-test/include/Makefile
> > config.status: creating core-test/Makefile
> > config.status: creating common/os/linux/include/Makefile
> > config.status: creating common/include/Makefile
> > config.status: creating common/Makefile
> > config.status: creating binary/include/Makefile
> > config.status: creating binary/Makefile
> > config.status: creating odbc/include/Makefile
> > config.status: creating odbc/Makefile
> > config.status: creating odbc-test/include/Makefile
> > config.status: creating odbc-test/Makefile
> > config.status: creating core/include/Makefile
> > config.status: creating core/Makefile
> > config.status: creating core/ignite.pc
> > config.status: creating jni/include/Makefile
> > config.status: creating jni/Makefile
> > config.status: creating ignite/Makefile
> > config.status: creating config.h
> > config.status: config.h is unchanged
> > config.status: executing depfiles commands
> > config.status: executing libtool commands
> > rm: cannot remove 'core': Is a directory
> >
> > Does this need some fixing, or am I missing some steps?
> >
>

[jira] [Created] (IGNITE-4724) AVG function always returns double type instead of the argument type

[Sergey Kozlov (JIRA)]

Sergey Kozlov created IGNITE-4724:
-

 Summary: AVG function always returns double type instead of the 
argument type
 Key: IGNITE-4724
 URL: https://issues.apache.org/jira/browse/IGNITE-4724
 Project: Ignite
  Issue Type: Bug
  Components: SQL
Affects Versions: 1.9
Reporter: Sergey Kozlov
 Fix For: 1.9


For H2:
SELECT AVG(intCol) FROM cache_part_2 AS part_2 WHERE (10*shortCol/100) > longCol
-[472]

For Ignite:
SELECT AVG(intCol) FROM AllTypes AS part_2 WHERE (10*shortCol/100) > longCol
+[472.2307692307692]




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

Re: Ignite 1.8 c++ Platform installation issue

[Igor Sapego]

Hi,

This is not an error. It comes from the Automake buildsystem considers
files named "core" to be a coredumps and tries to remove them. Ignite C++
has library named "core" with corresponding directory.

Shortly speaking, just ignore this message.

Best Regards,
Igor

On Sun, Feb 19, 2017 at 12:45 PM, Shashank Gandham <
shashankgand...@gmail.com> wrote:

> The ./configure command produces the following error:
>
> configure: creating ./config.status
> config.status: creating Makefile
> config.status: creating core-test/include/Makefile
> config.status: creating core-test/Makefile
> config.status: creating common/os/linux/include/Makefile
> config.status: creating common/include/Makefile
> config.status: creating common/Makefile
> config.status: creating binary/include/Makefile
> config.status: creating binary/Makefile
> config.status: creating odbc/include/Makefile
> config.status: creating odbc/Makefile
> config.status: creating odbc-test/include/Makefile
> config.status: creating odbc-test/Makefile
> config.status: creating core/include/Makefile
> config.status: creating core/Makefile
> config.status: creating core/ignite.pc
> config.status: creating jni/include/Makefile
> config.status: creating jni/Makefile
> config.status: creating ignite/Makefile
> config.status: creating config.h
> config.status: config.h is unchanged
> config.status: executing depfiles commands
> config.status: executing libtool commands
> rm: cannot remove 'core': Is a directory
>
> Does this need some fixing, or am I missing some steps?
>

[jira] [Created] (IGNITE-4723) .NET: Support REGEXP_LIKE in LINQ

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-4723:
--

 Summary: .NET: Support REGEXP_LIKE in LINQ
 Key: IGNITE-4723
 URL: https://issues.apache.org/jira/browse/IGNITE-4723
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn
 Fix For: 2.0


{{REGEXP_REPLACE}} H2 function is supported in LINQ via {{Regex.Replace}}, see 
{{MethodVisitor}}.

Add mapping for {{REGEXP_LIKE}} via {{Regex.IsMatch}}.



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

Re: [jira] [Created] (IGNITE-4680) Properly split batch atomic cache operations between stripes (putAll, removeAll, etc)

[Yakov Zhdanov]

Konstantin, please go ahead.

--Yakov

2017-02-11 20:18 GMT+03:00 Константин Дудков :

> Yakov,
>
> If you don't mind I would like to do this ticket.
>
> 10.02.2017, 16:31, "Yakov Zhdanov (JIRA)" :
> > Yakov Zhdanov created IGNITE-4680:
> > -
> >
> >  Summary: Properly split batch atomic cache operations
> between stripes (putAll, removeAll, etc)
> >  Key: IGNITE-4680
> >  URL: https://issues.apache.org/jira/browse/IGNITE-4680
> >  Project: Ignite
> >   Issue Type: Improvement
> >   Components: cache
> > Reporter: Yakov Zhdanov
> > Assignee: Yakov Zhdanov
> >  Fix For: 2.0
> >
> > Need to revisit keys/requests mapping procedure and map the update
> directly to stripe on remote node.
> > Here are some points:
> > # Abovementioned will require adding stripes count attribute to node's
> attribute list
> > # Need to make sure we take all benefits of biased locking and stripes
> never get mutually blocked
> > # locking all entries before processing request can be removed since it
> does not make too much sense to atomic cache
> >
> > --
> > This message was sent by Atlassian JIRA
> > (v6.3.15#6346)
>
> --
> С уважением,
> Константин Дудков
> kdud...@ya.ru
>

[jira] [Created] (IGNITE-4722) CacheRandomOperation benchmark: preloading as separate benchmarl with ability to load in a loop

[Ksenia Rybakova (JIRA)]

Ksenia Rybakova created IGNITE-4722:
---

 Summary: CacheRandomOperation benchmark: preloading as separate 
benchmarl with ability to load in a loop
 Key: IGNITE-4722
 URL: https://issues.apache.org/jira/browse/IGNITE-4722
 Project: Ignite
  Issue Type: Improvement
  Components: yardstick
Reporter: Ksenia Rybakova
 Fix For: 1.8


We need an ability to perform preloading (streaming) test for quite long time 
(2 hours or even more). Currently this might be done only by setting preloading 
amount parameter to some really big value. This requires lot of memory and many 
nodes in the cluster. This is not always possible due to hardware limits.
Suggest moving preloading from CacheRandomOperation benchmark to a separate one 
and add ability to perform it in a loop during predefined time.



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

Will take IGNITE-1264 Resource SPI

[ALEKSEY KUZNETSOV]

will take https://issues.apache.org/jira/browse/IGNITE-1264
-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: cache metadata progapagation

[Alexey Goncharuk]

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-1178 fix for NPE in GridCacheProcessor.onKernalStop()

[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  >:
>
> > 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*
>