Same Affinity For Same Key On All Caches

[Alper Tekinalp]

Hi all.

Is it possible to configures affinities in a way that partition for same
key will be on same node? So calling
ignite.affinity(CACHE).mapKeyToNode(KEY).id() with same key for any cache
will return same node id. Is that possible with a configuration etc.?

-- 
Alper Tekinalp

Software Developer
Evam Streaming Analytics

Atatürk Mah. Turgut Özal Bulv.
Gardenya 5 Plaza K:6 Ataşehir
34758 İSTANBUL

Tel:  +90 216 455 01 53 Fax: +90 216 455 01 54
www.evam.com.tr

Re: IGNITE-3422 - ready for review

[Denis Magda]

In my understanding the goal is well-defined in the ticket. At the same time we 
have a similar task prepared by Pavel for .NET:
https://issues.apache.org/jira/browse/IGNITE-3102 


So, what we need to agree on is how to proceed with the implementation. Let us 
think this over and propose design.

—
Denis

> On Feb 22, 2017, at 2:41 AM, Vyacheslav Daradur  wrote:
> 
> Guys, let's discuss a goal of this task.
> 
> I need the task specification.
> 
> 
> 2017-02-22 2:00 GMT+03:00 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: IGNITE-602 - ready for review

[Denis Magda]

Dmitriy, thanks!

Someone from the community will help with the review soon.

—
Denis

> On Feb 22, 2017, at 2:23 AM, Дмитрий Рябов  wrote:
> 
> Hello. Please, review.
> 
> https://issues.apache.org/jira/browse/IGNITE-602 [Test] GridToStringBuilder
> is vulnerable for StackOverflowError caused by infinite recursion
> 
> CI tests:
> http://ci.ignite.apache.org/project.html?projectId=IgniteTes
> ts_IgniteTests=pull%2F1558%2Fhead

Re: Contributor access

[Denis Magda]

Hi Jeyhun,

Looks like you were added to the contributor’s list before. So you’re set. Go 
ahead and pick a ticket of interest.

Below you can find information that might be useful for you.

Get familiar with Ignite development process described here:
https://cwiki.apache.org/confluence/display/IGNITE/Development+Process

Instructions on how to contribute can be found here:
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute

Project setup in Intellij IDEAL
https://cwiki.apache.org/confluence/display/IGNITE/Project+Setup

Once you got familiar and were able to run a few examples, you should pick
a Jira ticket you would like to start on. Send an email to the dev list, so
we can add you as a contributor in Jira.

These are the easy tickets to start with:
https://issues.apache.org/jira/browse/IGNITE-4549?jql=project%20%3D%20IGNITE%20AND%20labels%20in%20(newbie)%20and%20status%20%3D%20OPEN

While those are more advanced but appealing:
https://ignite.apache.org/community/contribute.html#pick-ticket 


—
Denis

> On Feb 22, 2017, at 3:34 PM, Jeyhun Karimov  wrote:
> 
> Dear Ignite community,
> 
> Can you please grant me (jeyhunkarimov) contributor access so that I can
> assign Ignite jira issues to myself ?
> 
> -Best
> Jeyhun
> -- 
> -Cheers
> 
> Jeyhun

[jira] [Created] (IGNITE-4749) Advanced testing of Kubernetes IP finder

[Denis Magda (JIRA)]

Denis Magda created IGNITE-4749:
---

 Summary: Advanced testing of Kubernetes IP finder
 Key: IGNITE-4749
 URL: https://issues.apache.org/jira/browse/IGNITE-4749
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda


Test coverage of Kubernetes IP finder has to be extended. We need to find a way 
on how to start a Kubernetes single node cluster as a part of unit tests and 
check the following:
- Ignite pods are able to discover each other.
- The cluster can be scaled out or scaled in using standard Kubernetes API.



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

Re: IGNITE-2741 - spring session design

[Valentin Kulichenko]

Hi Rishi,

Got it, I think I'm reproducing the issue. I'll take a look and let you
know my findings soon.

-Val

On Tue, Feb 21, 2017 at 7:27 PM, Rishi Yagnik  wrote:

> Hi Val,
>
> The issue will occur in cluster environment, please setup the spring boot
> on 2 different host with LB (F5 OR Reverse proxy) in front and try to
> login.
>
> In cluster environment, Spring security does not recognize the session on
> the host you are not logged in, as a result, spring security will redirect
> to login url however the correct behavior should be that user would stay
> logged in with session replication.
>
> Do let me know if you need more information.
>
> Thanks,
> Rishi
>
>
>
> On Tue, Feb 21, 2017 at 7:08 PM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Hi Rishi,
> >
> > I was able to build and run the application. Can you give some
> description
> > on what should I test to understand the issue? What exactly didn't work
> for
> > you?
> >
> > -Val
> >
> > On Wed, Feb 15, 2017 at 10:52 AM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > > Hi Rishi,
> > >
> > > Thanks, I'll take a look.
> > >
> > > -Val
> > >
> > > On Wed, Feb 15, 2017 at 9:07 AM, Rishi Yagnik 
> > > 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 

Re: IGNITE-13

[Valentin Kulichenko]

Hi Vadim,

Thanks, I will review this week.

-Val

On Wed, Feb 22, 2017 at 2:28 AM, Вадим Опольский 
wrote:

> Hi Valentin!
>
> https://issues.apache.org/jira/browse/IGNITE-13
>
> I created BinaryWriterExImplNew (extended of BinaryWriterExImpl) and
> added new methods with changes described in the ticket
>
> https://github.com/javaller/MyBenchmark/blob/master/src/
> main/java/org/sample/BinaryWriterExImplNew.java
>
> I created a benchmark for BinaryWriterExImplNew
>
> https://github.com/javaller/MyBenchmark/blob/master/src/
> main/java/org/sample/ExampleTest.java
>
> I run benchmark and compared results
>
> https://github.com/javaller/MyBenchmark/blob/master/totalstat.txt
>
> # Run complete. Total time: 00:10:24
> BenchmarkMode  CntScore
> Error  Units
> ExampleTest.binaryHeapOutputStream1  avgt   50  1114999,207 ±
> 16756,776  ns/op
> ExampleTest.binaryHeapOutputStream2  avgt   50  1118149,320 ±
> 17515,961  ns/op
> ExampleTest.binaryHeapOutputStream3  avgt   50  1113678,657 ±
> 17652,314  ns/op
> ExampleTest.binaryHeapOutputStream4  avgt   50  1112415,051 ±
> 18273,874  ns/op
> ExampleTest.binaryHeapOutputStream5  avgt   50  366,583 ±
> 18282,829  ns/op
> ExampleTest.binaryHeapOutputStreamACSII   avgt   50  1112079,667 ±
> 16659,532  ns/op
> ExampleTest.binaryHeapOutputStreamUTFCustom  avgt   50  1114949,759 ±
> 16809,669  ns/op
> ExampleTest.binaryHeapOutputStreamUTFNIOavgt   50  1121462,325 ±
> 19836,466  ns/op
>
> Is it OK? Whats the next step? Do I have to move this JMH benchmark to the
> Ignite project ?
>
> Vadim Opolski
>
>
>
>
>
>
>
>
> 2017-02-21 1:06 GMT+03:00 Valentin Kulichenko <
> valentin.kuliche...@gmail.com>:
>
>> 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, 

[GitHub] ignite pull request #1532: IGNITE-533: Implement IgniteZeromqStreamer to str...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-4748) jdbc2.JdbcStatement does not implement setQueryTimeout method

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-4748:
---

 Summary: jdbc2.JdbcStatement does not implement setQueryTimeout 
method
 Key: IGNITE-4748
 URL: https://issues.apache.org/jira/browse/IGNITE-4748
 Project: Ignite
  Issue Type: Bug
  Components: jdbc-driver
Affects Versions: 1.8
Reporter: Valentin Kulichenko
Priority: Critical
 Fix For: 1.9


The method was implemented in the older version of JDBC driver, but was missed 
in the newer version (still throws exception).



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

Contributor access

[Jeyhun Karimov]

Dear Ignite community,

Can you please grant me (jeyhunkarimov) contributor access so that I can
assign Ignite jira issues to myself ?

-Best
Jeyhun
-- 
-Cheers

Jeyhun

[jira] [Created] (IGNITE-4747) Memory leak on massive cache operations over atomic cache

[Vladislav Pyatkov (JIRA)]

Vladislav Pyatkov created IGNITE-4747:
-

 Summary: Memory leak on massive cache operations over atomic cache
 Key: IGNITE-4747
 URL: https://issues.apache.org/jira/browse/IGNITE-4747
 Project: Ignite
  Issue Type: Bug
Reporter: Vladislav Pyatkov


When starts several nodes (I have tested in 4 nodes) with the application, 
through some time (depends of heap size), we have got a Full GC pause and 
segmentation the grid.
After heap dump analysis, I found some suspicious object:
{noforamt}
  Class Instance Count Total Size 
class java.util.concurrent.ConcurrentSkipListMap$Node  63622411  1526937864  
class java.util.concurrent.ConcurrentSkipListMap$Index  31810595  763454280  
class java.lang.Long  63622318  508978544  
{noforamt}

the leak in the fils "updates" of class GridDhtLocalPartition.



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

[GitHub] ignite pull request #1570: IGNITE-4745: Removed unused targetver.h files

[isapego]

GitHub user isapego opened a pull request:

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

IGNITE-4745: Removed unused targetver.h files



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

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

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

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


commit 730c41754dda2f42dc204c397bf7550637ebfd2a
Author: Igor Sapego 
Date:   2017-02-22T12:57:58Z

IGNITE-4745: Removed unused targetver.h files




---
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-4746) Add documentation for SQL query parallelism

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4746:
---

 Summary: Add documentation for SQL query parallelism
 Key: IGNITE-4746
 URL: https://issues.apache.org/jira/browse/IGNITE-4746
 Project: Ignite
  Issue Type: Task
  Components: documentation, SQL
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 1.9


See IGNITE-4106.



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

[jira] [Created] (IGNITE-4745) CPP: remove unsused targetver.h files

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-4745:
---

 Summary: CPP: remove unsused targetver.h files
 Key: IGNITE-4745
 URL: https://issues.apache.org/jira/browse/IGNITE-4745
 Project: Ignite
  Issue Type: Task
  Components: platforms
Affects Versions: 1.8
Reporter: Igor Sapego
Assignee: Igor Sapego
 Fix For: 1.9


Currently, there are {{targetver.h}} files in {{common}} and {{jni}} libs of 
the C++ client:
- modules/platforms/cpp/common/project/vs/targetver.h
- modules/platforms/cpp/jni/project/vs/targetver.h

They are not used as for now so remove them.



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

[jira] [Created] (IGNITE-4744) visorcmd: task command doesn't show any tasks running on grid

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-4744:
--

 Summary: visorcmd: task command doesn't show any tasks running on 
grid
 Key: IGNITE-4744
 URL: https://issues.apache.org/jira/browse/IGNITE-4744
 Project: Ignite
  Issue Type: Bug
  Components: visor
Affects Versions: 1.9
Reporter: Pavel Konstantinov


I faced that visorcmd doesn't show any tasks that I running using my test load.



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

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

[asfgit]

Github user asfgit closed the pull request at:

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


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

[Alexander Fedotov]

Hi,
Take a look at log4j-test.xml and tests.properties.

On Wed, Feb 22, 2017 at 2:33 PM, ALEKSEY KUZNETSOV  wrote:

> Guys! How to enable debug level logging in tests ? Ignite logger works
> oddly and doesn't take proper config into account
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>



-- 
Kind regards,
Alexander.

[jira] [Created] (IGNITE-4743) Set AUTO_COPY to false when it wasn't define in properties file

[Ilya Suntsov (JIRA)]

Ilya Suntsov created IGNITE-4743:


 Summary: Set AUTO_COPY to false when it wasn't define in 
properties file
 Key: IGNITE-4743
 URL: https://issues.apache.org/jira/browse/IGNITE-4743
 Project: Ignite
  Issue Type: Bug
Reporter: Ilya Suntsov


In case when in properties file there isn't variable AUTO_COPY we automatically 
set it to true. It's wrong. 
We should add condition if AUTO_COPY doesn't exist in property file then set it 
to false.



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

[GitHub] ignite pull request #1569: IGNITE-4742 IgniteCacheUpdateSqlQuerySelfTest.tes...

[alexpaschenko]

GitHub user alexpaschenko opened a pull request:

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

IGNITE-4742 IgniteCacheUpdateSqlQuerySelfTest.testTypeConversions fix



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

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

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

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


commit ceffb95bc9301c716d7e35c3e80d6fd46ac7a34c
Author: Alexander Paschenko 
Date:   2017-02-22T10:31:24Z

IGNITE-4742 IgniteCacheUpdateSqlQuerySelfTest.testTypeConversions 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-4742) Flaky IgniteCacheUpdateSqlQuerySelfTest.testTypeConversions

[Alexander Paschenko (JIRA)]

Alexander Paschenko created IGNITE-4742:
---

 Summary: Flaky 
IgniteCacheUpdateSqlQuerySelfTest.testTypeConversions
 Key: IGNITE-4742
 URL: https://issues.apache.org/jira/browse/IGNITE-4742
 Project: Ignite
  Issue Type: Bug
  Components: SQL
Affects Versions: 1.8
Reporter: Alexander Paschenko
Assignee: Alexander Paschenko
Priority: Minor
 Fix For: 1.9


This test fails randomly on various query related suites and very seldom 
locally. Seems to be test problem and not of what is tested.



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

Re: IGNITE-13

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

Hi Valentin!

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

I created BinaryWriterExImplNew (extended of BinaryWriterExImpl) and added
new methods with changes described in the ticket

https://github.com/javaller/MyBenchmark/blob/master/src/main/java/org/sample/BinaryWriterExImplNew.java

I created a benchmark for BinaryWriterExImplNew

https://github.com/javaller/MyBenchmark/blob/master/src/main/java/org/sample/ExampleTest.java

I run benchmark and compared results

https://github.com/javaller/MyBenchmark/blob/master/totalstat.txt

# Run complete. Total time: 00:10:24
BenchmarkMode  CntScore
Error  Units
ExampleTest.binaryHeapOutputStream1  avgt   50  1114999,207 ±
16756,776  ns/op
ExampleTest.binaryHeapOutputStream2  avgt   50  1118149,320 ±
17515,961  ns/op
ExampleTest.binaryHeapOutputStream3  avgt   50  1113678,657 ±
17652,314  ns/op
ExampleTest.binaryHeapOutputStream4  avgt   50  1112415,051 ±
18273,874  ns/op
ExampleTest.binaryHeapOutputStream5  avgt   50  366,583 ±
18282,829  ns/op
ExampleTest.binaryHeapOutputStreamACSII   avgt   50  1112079,667 ±
16659,532  ns/op
ExampleTest.binaryHeapOutputStreamUTFCustom  avgt   50  1114949,759 ±
16809,669  ns/op
ExampleTest.binaryHeapOutputStreamUTFNIOavgt   50  1121462,325 ±
19836,466  ns/op

Is it OK? Whats the next step? Do I have to move this JMH benchmark to the
Ignite project ?

Vadim Opolski








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 

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

[NSAmelchev]

Github user NSAmelchev closed the pull request at:

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


---
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 #1568: IGNITE-4741 JDBC DML streaming test fix

[alexpaschenko]

GitHub user alexpaschenko opened a pull request:

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

IGNITE-4741 JDBC DML streaming test fix



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

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

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

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


commit 416f427434f143f32c2e04943c8cd8c98a5bca1e
Author: Alexander Paschenko 
Date:   2017-02-22T10:10:53Z

IGNITE-4741 JDBC DML streaming test 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.
---

Re: IGNITE-3422 - ready for review

[Vyacheslav Daradur]

Guys, let's discuss a goal of this task.

I need the task specification.


2017-02-22 2:00 GMT+03:00 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: IGNITE-4284 - ready for review

[Alexey Goncharuk]

Nikita,

The fix looks wrong to me. The point of the assertion was to ensure an
invariant,
see 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager#executeQuery
-V2 handler is created only when remote filter factory is not null.

The test observes both fields equal to null because deserialization failed
because peer class loading is not supported in certain places of code in
Ignite (namely, discovery subsystem), and joining node receives registered
continuous queries through discovery data. Silent ignorance of this failure
is wrong, we should either forbid such a node to start or support p2p class
loading for discovery (or suggest yet another solution).

2017-02-22 12:03 GMT+03:00 Nikita Amelchev :

> Hello. I fixed it.
>
> Please, review.
>
> https://issues.apache.org/jira/browse/IGNITE-4284 - Failed second client
> node join with continuous query and peer class loading enabled
>
> latest ci.tests:
> http://ci.ignite.apache.org/project.html?projectId=IgniteTests_
> IgniteTests=pull%2F1564%2Fhead
>
>
> --
> Best wishes,
> Amelchev Nikita
>

IGNITE-602 - ready for review

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

Hello. Please, review.

https://issues.apache.org/jira/browse/IGNITE-602 [Test] GridToStringBuilder
is vulnerable for StackOverflowError caused by infinite recursion

CI tests:
http://ci.ignite.apache.org/project.html?projectId=IgniteTes
ts_IgniteTests=pull%2F1558%2Fhead

[jira] [Created] (IGNITE-4741) JdbcStreamingSelfTest is not reliable

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4741:
---

 Summary: JdbcStreamingSelfTest is not reliable
 Key: IGNITE-4741
 URL: https://issues.apache.org/jira/browse/IGNITE-4741
 Project: Ignite
  Issue Type: Test
  Components: jdbc-driver
Affects Versions: 1.8
Reporter: Vladimir Ozerov
Assignee: Alexander Paschenko
Priority: Minor
 Fix For: 1.9


Test fails from time to time because it waits for some conditions based on 
{{Thread.sleep(1000L}}, which is not reliable enough.



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

IGNITE-4284 - ready for review

[Nikita Amelchev]

Hello. I fixed it.

Please, review.

https://issues.apache.org/jira/browse/IGNITE-4284 - Failed second client
node join with continuous query and peer class loading enabled

latest ci.tests:
http://ci.ignite.apache.org/project.html?projectId=IgniteTests_IgniteTests=pull%2F1564%2Fhead


-- 
Best wishes,
Amelchev Nikita