Re: Hello

[Denis Magda]

Good afternoon!

> On Nov 8, 2017, at 1:11 PM, Sérgio Manuel Pereira Simões 
>  wrote:
> 
> Hello

Re: request for contributors permissions

[Denis Magda]

Oleg,

The JIRA permissions were granted. Please go ahead and pick a ticket you like.

—
Denis

> On Nov 7, 2017, at 11:12 PM, Олег Салахутдинов  wrote:
> 
> Hello Denis, 
> 
> My JIRA id is of.salakhutdinov and I am planning to resolve bugs.
> 
> 
> Best regards,
> Oleg Salakhutdinov.
> 
> 
> Среда, 8 ноября 2017, 3:09 +03:00 от Denis Magda :
> 
> Hello Oleg,
> 
> What’s your JIRA id and what kind of contribution are you planning to do for 
> Ignite?
> 
> —
> Denis
> 
> > On Nov 7, 2017, at 5:46 AM, Олег Салахутдинов  > > wrote:
> > 
> > 
> > 
> > 
> > -- 
> > С Уважением
> > Салахутдинов Олег Федорович
> > т. 8(925)060-43-02
> > skype: oleja_raevskiy
> 
> 
> 
> -- 
> С Уважением
> Салахутдинов Олег Федорович
> т. 8(925)060-43-02
> skype: oleja_raevskiy

Additional method for segment checks

[luqmanahmad]

Hi there,

I have started to work on segmentation checks and noticed that we are
missing a method from IgniteConfiguration which could be useful.

For example let say we have 3 segmentation resolver and we want all of them
to be passed we set the setAllSegmentationResolversPassRequired(true) but
what if we want to pass any 2 of them.

I think there should be a method available in
IgniteConfiguration#setMinSegmentsPass (int) which should be greater than
total segments, and it can be ignored in case
setAllSegmentationResolversPassRequired is set to true (ofcourse that would
depend on custom implementation of the plugin).

Let me know your thoughts.

Thanks,
Luqman





--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

Re: Identifying grid transactions

[Valentin Kulichenko]

Yakov,

Here is the ticket: https://issues.apache.org/jira/browse/IGNITE-6847

Feel free to add if I missed anything.

-Val

On Tue, Oct 10, 2017 at 3:22 AM, Yakov Zhdanov  wrote:

> Val, I really like your idea to implement common mechanism for all APIs.
> Can you please file a ticket?
>
> --Yakov
>

[jira] [Created] (IGNITE-6847) Add an ability to provide custom per operation context

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-6847:
---

 Summary: Add an ability to provide custom per operation context
 Key: IGNITE-6847
 URL: https://issues.apache.org/jira/browse/IGNITE-6847
 Project: Ignite
  Issue Type: Improvement
  Security Level: Public (Viewable by anyone)
  Components: general
Affects Versions: 2.3
Reporter: Valentin Kulichenko


Sometimes it's useful to attach custom context information to a distributed 
operation. For example, an application that uses Ignite cluster may want to 
provide its own ID or name so that it could then be used on other nodes for 
auditing purposes.

To support this, we can introduce {{withTag(Serializable tag)}} method on 
{{IgniteCache}}, {{IgniteCompute}} and other APIs. If provided, tag is attached 
to every remote request and propagated to log messages, events, etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Misleading query duration metrics

[Valentin Kulichenko]

Andrey,

I think you're right. This logic was once refactored so that actual
execution happens only when cursor iteration starts, and I guess metrics
were not fixed accordingly. Can you file a ticket?

-Val

On Wed, Nov 8, 2017 at 9:27 AM, Andrey Kornev 
wrote:

> (Changed the subject to maybe make people actually read the posting.)
>
> Anyway, if somebody (who knows that code) could take a quick look to see
> if the duration is indeed computed correctly (or not), that would be
> greatly appreciated!
>
> Thanks
> Andrey
>
> 
> From: Andrey Kornev 
> Sent: Sunday, November 5, 2017 12:17 PM
> To: dev@ignite.apache.org
> Subject: Query duration metrics
>
> Hi,
>
> It appears as if the query duration metric is a bit misleading.
>
> GridQueryProcessor.executeQuery() doesn't actually "run" the query. It
> simply delegates query execution to a closure passed in as a parameter. The
> closure may or may not actually execute the query. In some (all?) cases,
> the closure simply creates and returns an Iterable (how does
> IgniteH2Indexing.runQueryTwoStep, for example). Actual query execution
> happens at some point later when user instantiates an Iterator from the
> Iterable. What's in fact recorded (by GridQueryProcessor on line 2477) as
> the "query duration" is just the query parsing stage as well as some
> query's AST manipulation logic that tries to convert the regular regular
> query to a map/reduce style query. So, it's basically a "prepare statement
> duration" that is currently reported as "query duration".
>
> Am I missing something?
>
> Thanks
> Andrey
>

Re: JMSStreamer enhancement -- needs to support multiple IgniteDataStreamers.

[Dmitriy Setrakyan]

On Thu, Nov 9, 2017 at 5:06 AM, Timothy Steffens  wrote:

> Can the JMSStreamer be configured to inspect the message prior to picking
> it off of the queue? If so, then I can use multiple JMSStreamers as you
> suggest. If not, then I cannot since each JMSStreamer will not know if the
> next message is for them or for another to process. I do not want to have
> multiple queues (one queue per table - which would equate to one
> JMSStreamer per queue) due to ongoing maintenance concerns.
>

To be honest, queue-per-table seems like the most appropriate solution
here. I do not think inspecting messages before they get picked off the
queue will perform well.

If queue-per-table is not possible, then my suggestion would be not to use
JMS Streamer at all, and implement your own logic for reading JMS messages
and passing them off to the appropriate data streamer.

D.

Re: JMSStreamer enhancement -- needs to support multiple IgniteDataStreamers.

[Timothy Steffens]

 Can the JMSStreamer be configured to inspect the message prior to picking it 
off of the queue? If so, then I can use multiple JMSStreamers as you suggest. 
If not, then I cannot since each JMSStreamer will not know if the next message 
is for them or for another to process. I do not want to have multiple queues 
(one queue per table - which would equate to one JMSStreamer per queue) due to 
ongoing maintenance concerns.

On Wednesday, November 8, 2017, 1:45:33 PM CST, Dmitriy Setrakyan 
 wrote:  
 
 Tim,

I am not sure why we need to change the JMS streamer. Why not just create a
separate JMS streamer per cache? In my view, it is more intuitive to keep
one-to-one relationship between JMS streamer and the data streamer.

D.

On Wed, Nov 8, 2017 at 9:40 AM, Timothy Steffens <
timothy.steff...@yahoo.com.invalid> wrote:

> Dev -
>
> I have a use case that is not able to be addressed with the existing
> JMSStreamer functionality so I would like to propose an enhancement.
>
> The use case is such that I have a series of database tables and am
> writing messages into a shared JMS queue for each table update. These
> messages are then picked up by the JMSStreamer, converted into various
> object types (based on an indicator within the message), and written into a
> shared Ignite cache that holds all object types. I would like to enhance
> the JMSStreamer so that it accepts multiple IgniteDataStreamer instances so
> that it can stream each object type into its own corresponding cache rather
> than having to stream into a shared, generic cache.
>
> My approach will be to take advantage of the inherited StreamAdapter
> functionality within the JMSStreamer. Note that my changes will be
> backwards compatible so that other streamers are not broken. Additionally,
> these changes will streamline the message processing functionality which is
> duplicated between the StreamAdapter and JMSStreamer today.
>
>
> StreamAdapter
>  - Update the StreamAdapter to accept a list of IgniteDataStreamers - the
> getStreamer() method will be kept for backwards compatibility and I will
> add getStreamers().
>
>  - The StreamAdapter's addMessage() method now has to interrogate the
> Message type to determine onto which streamer to place the message. This
> can be done by providing a custom map that relates the message type to a
> specific streamer.
>
>
> JMSStreamer
>  - Update the JMSStreamer add a setStreamers() method that takes a list
> of streamers - the setStreamer() method will be left for backwards
> compatibility.
>
>  - The start() method is updated to verify the list of streamers is not
> null and to verify that a Single/MultipleTupleExtractor was provided
> instead of a MessageTransformer.
>
>  - Mark the setTransformer() method as deprecated.
>
>  - The executor.execute() method is updated to use the inherited
> addMessage() method from StreamAdapter.
>
>  - Delete the JMSStreamer private processMethod() after refactoring to
> use the StreamAdapter addMessage() method.
>
>  - Remove the MessageTransformer property from the JMSStreamer because it
> will now use the Single/MultipleTupleExtractor within the StreamAdapter -
> these two classes do basically the same thing. The MessageTransformer class
> can then be deprecated and go away as it is not used anywhere else in the
> code base.
>
>
> MessageTransformer
>  - Mark as deprecated.
>
>
>
> Please review and let me know how to proceed.
>
> Thank you.
>
  

Hello

[Sérgio Manuel Pereira Simões]

Hello

[jira] [Created] (IGNITE-6846) Add metrics for entry processor invocations

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-6846:
---

 Summary: Add metrics for entry processor invocations
 Key: IGNITE-6846
 URL: https://issues.apache.org/jira/browse/IGNITE-6846
 Project: Ignite
  Issue Type: Improvement
  Security Level: Public (Viewable by anyone)
  Components: cache
Affects Versions: 2.3
Reporter: Valentin Kulichenko


{{CacheMetrics}} object has multiple metrics for various cache operations like 
{{get}}, {{put}} and {{remove}}, but nothing for {{invoke}}/{{EntryProcessor}}. 
It makes sense to add such metrics, for example:
* Total number of `invoke` operations executed.
* Number of `invoke` operations that included updates.
* Number of read-only `invoke` operations.
* Min/max/avg execution time.
* ...



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: JMSStreamer enhancement -- needs to support multiple IgniteDataStreamers.

[Dmitriy Setrakyan]

Tim,

I am not sure why we need to change the JMS streamer. Why not just create a
separate JMS streamer per cache? In my view, it is more intuitive to keep
one-to-one relationship between JMS streamer and the data streamer.

D.

On Wed, Nov 8, 2017 at 9:40 AM, Timothy Steffens <
timothy.steff...@yahoo.com.invalid> wrote:

> Dev -
>
> I have a use case that is not able to be addressed with the existing
> JMSStreamer functionality so I would like to propose an enhancement.
>
> The use case is such that I have a series of database tables and am
> writing messages into a shared JMS queue for each table update. These
> messages are then picked up by the JMSStreamer, converted into various
> object types (based on an indicator within the message), and written into a
> shared Ignite cache that holds all object types. I would like to enhance
> the JMSStreamer so that it accepts multiple IgniteDataStreamer instances so
> that it can stream each object type into its own corresponding cache rather
> than having to stream into a shared, generic cache.
>
> My approach will be to take advantage of the inherited StreamAdapter
> functionality within the JMSStreamer. Note that my changes will be
> backwards compatible so that other streamers are not broken. Additionally,
> these changes will streamline the message processing functionality which is
> duplicated between the StreamAdapter and JMSStreamer today.
>
>
> StreamAdapter
>   - Update the StreamAdapter to accept a list of IgniteDataStreamers - the
> getStreamer() method will be kept for backwards compatibility and I will
> add getStreamers().
>
>   - The StreamAdapter's addMessage() method now has to interrogate the
> Message type to determine onto which streamer to place the message. This
> can be done by providing a custom map that relates the message type to a
> specific streamer.
>
>
> JMSStreamer
>   - Update the JMSStreamer add a setStreamers() method that takes a list
> of streamers - the setStreamer() method will be left for backwards
> compatibility.
>
>   - The start() method is updated to verify the list of streamers is not
> null and to verify that a Single/MultipleTupleExtractor was provided
> instead of a MessageTransformer.
>
>   - Mark the setTransformer() method as deprecated.
>
>   - The executor.execute() method is updated to use the inherited
> addMessage() method from StreamAdapter.
>
>   - Delete the JMSStreamer private processMethod() after refactoring to
> use the StreamAdapter addMessage() method.
>
>   - Remove the MessageTransformer property from the JMSStreamer because it
> will now use the Single/MultipleTupleExtractor within the StreamAdapter -
> these two classes do basically the same thing. The MessageTransformer class
> can then be deprecated and go away as it is not used anywhere else in the
> code base.
>
>
> MessageTransformer
>   - Mark as deprecated.
>
>
>
> Please review and let me know how to proceed.
>
> Thank you.
>

[jira] [Created] (IGNITE-6845) WebSessionFilter cannot handle liberty session ids

[Andreas Weber (JIRA)]

Andreas Weber created IGNITE-6845:
-

 Summary: WebSessionFilter cannot handle liberty session ids
 Key: IGNITE-6845
 URL: https://issues.apache.org/jira/browse/IGNITE-6845
 Project: Ignite
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
Reporter: Andreas Weber


h2. Problem:

Websphere Liberty creates session ids in the following form (way the session id 
is serialized in the cookie):
:
e.g. 3XeX_c5NHR5fJLYufFzt5ka:a3e94cfd-b391-4d9b-b9e7-6ddfcbf8c334

If a request is received by the same instance where the session was created, 
the requested session id is only the  part.
If a request is received by the another instance, the requested session id is 
the complete
:

Because of this behavior, Ignite searches for : in 
the cache, but only  was stored.

h2. Solution:

Implement a sessionIdTransformer for Websphere Liberty that normalizes 
: to 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Misleading query duration metrics

[Andrey Kornev]

(Changed the subject to maybe make people actually read the posting.)

Anyway, if somebody (who knows that code) could take a quick look to see if the 
duration is indeed computed correctly (or not), that would be greatly 
appreciated!

Thanks
Andrey


From: Andrey Kornev 
Sent: Sunday, November 5, 2017 12:17 PM
To: dev@ignite.apache.org
Subject: Query duration metrics

Hi,

It appears as if the query duration metric is a bit misleading.

GridQueryProcessor.executeQuery() doesn't actually "run" the query. It simply 
delegates query execution to a closure passed in as a parameter. The closure 
may or may not actually execute the query. In some (all?) cases, the closure 
simply creates and returns an Iterable (how does 
IgniteH2Indexing.runQueryTwoStep, for example). Actual query execution happens 
at some point later when user instantiates an Iterator from the Iterable. 
What's in fact recorded (by GridQueryProcessor on line 2477) as the "query 
duration" is just the query parsing stage as well as some query's AST 
manipulation logic that tries to convert the regular regular query to a 
map/reduce style query. So, it's basically a "prepare statement duration" that 
is currently reported as "query duration".

Am I missing something?

Thanks
Andrey

[GitHub] ignite pull request #3004: Ignite 6411 benchmark

[anton-vinogradov]

GitHub user anton-vinogradov opened a pull request:

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

Ignite 6411 benchmark



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

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

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

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


commit 097eddbb5b886b82807861987ecc690947d216dd
Author: Anton Vinogradov 
Date:   2017-10-11T13:38:19Z

IGNITE-6411 Benchmark

commit 2e751f5c0bceb3f78e6fb7a2aa5b62cdff5583e0
Author: Anton Vinogradov 
Date:   2017-10-12T14:28:07Z

IGNITE-6411 Benchmark

commit 2b7e27d3eeadb05ed903a8ef7145eb5649af7584
Author: Anton Vinogradov 
Date:   2017-10-12T15:19:41Z

IGNITE-6411 Benchmark

commit 9f3388deb0405517e10c604ea6788b29f809ff04
Author: Anton Vinogradov 
Date:   2017-10-12T15:23:43Z

IGNITE-6411 Benchmark

commit d1ba832491e0d4be9a816d786758460a9a096796
Author: Anton Vinogradov 
Date:   2017-10-13T12:14:29Z

IGNITE-6411 Benchmark

commit 51bb860dd30329fc7dc177b9b3bc967e71f0a7c9
Author: Anton Vinogradov 
Date:   2017-10-13T12:40:39Z

IGNITE-6411 Benchmark

commit a418b719f3aa9ec966773265a0d4659833c0fb07
Author: Anton Vinogradov 
Date:   2017-10-17T11:52:05Z

IGNITE-6411 Benchmark

commit e9726d4d65809e29c993a5a464e692c76ebb1634
Author: Anton Vinogradov 
Date:   2017-10-17T11:52:23Z

IGNITE-6411 Benchmark

commit 11e877abc63dd6a082c8ae81d6eb1625eb2e9151
Author: Anton Vinogradov 
Date:   2017-10-19T12:51:00Z

IGNITE-6648 ML javadoc is missing in 2.2 binary release

(cherry picked from commit ae793a5)

commit a9d771b79afbe6952da3e7e7081898c21b65eed0
Author: Anton Vinogradov 
Date:   2017-10-20T13:33:24Z

Merge remote-tracking branch 'remotes/origin/master' into 
ignite-6411-benchmark

commit 1c48de4e3ff82e072251126c55a0686b30aa9e66
Author: Anton Vinogradov 
Date:   2017-10-20T13:35:22Z

IGNITE-6658 Add a version of Ignite instance to logger category

commit 7947b4974e306474f06b27aa6796dcf2995fedae
Author: Anton Vinogradov 
Date:   2017-10-20T15:23:31Z

Removed redundant libs from libs/optional

(cherry picked from commit 347696d)

commit a6d6194a6be4e7f58ba0e774eaec28060022193b
Author: Anton Vinogradov 
Date:   2017-10-24T15:35:21Z

force checkpoint

commit b408b14ee1955d32317967bcc44bed542ee1a6cc
Author: Anton Vinogradov 
Date:   2017-10-31T09:59:28Z

IGNITE-6411

commit 91b201d630f96c0e3411350d6924e1b5b503ca93
Author: Anton Vinogradov 
Date:   2017-10-31T09:59:55Z

IGNITE-6411

commit cb5a5adbd2323d0262ed0f8d62a0a83e6a09cf6c
Author: Anton Vinogradov 
Date:   2017-11-08T16:49:40Z

IGNITE-6411 WIP

commit ab376ff3ef84a8b2c3dcea33ddf420ae5634ce14
Author: Anton Vinogradov 
Date:   2017-11-08T16:51:43Z

Merge remote-tracking branch 'remotes/origin/master' into 
ignite-6411-benchmark




---

Re: Conflicting cross-version suffixes in: org.scalatest:scalatest, com.twitter:chill, org.apache.spark:spark-unsafe, org.apache.spark:spark-tags

[Николай Ижиков]

Hello, Denis.

I know about this issue.
I can try to fix it.

But, seems that ticket assigned to you, currently.
Let me know if you need some kind of help.



2017-11-08 18:17 GMT+03:00 Николай Ижиков :

> Привет.
>
> Я знаю об этой проблеме. Натолкнулся на неё при реализации Spark DataFrame
> API для Ignite.
> Могу попробовать починить, но баг сейчас на тебе и в In Progress.
>
> Ты его чинишь?
>
>
> 2017-11-08 17:49 GMT+03:00 Denis Mekhanikov :
>
>> Igniters,
>>
>> I noticed a problem in POM files of *ignite-spark* and *ignite-spark_2.10*
>>  modules.
>>
>> *ignite-spark* is targeted to be used by Scala 2.11, while
>> *ignite-spark_2.10* is made for Scala 2.10.
>> *But, **ignite-spark* has *spark-unsafe_2.10* as a dependency, and
>> *ignite-spark_2.10* depends on *json4s-core_2.11*.
>> It results in that when you add *ignite-spark *module as a dependency to
>> your SBT project, it stops compiling with the following error:
>> Modules were resolved with conflicting cross-version suffixes
>>
>> Nikolay Izhikov, Valentin Kulichenko, can you comment on this? Is it some
>> kind of a hack, or these dependencies are just specified by mistake?
>> There is a ticket for this issue:
>> https://issues.apache.org/jira/browse/IGNITE-6369
>>
>> Denis
>>
>> пт, 6 окт. 2017 г. в 16:44, manuelmourato :
>>
>> > Hi, thank you for taking an interest in this bug.
>> > I managed to compile my project successfully by taking Val's suggestion,
>> > changing this:
>> >
>> > 
>> > org.json4s
>> > json4s-core_2.10
>> > 3.5.0
>> > 
>> >
>> > I noticed that I couldn't compile using ignite version 2.3, I had to
>> > downgrade to 2.2, otherwise this error would show up:
>> >
>> > [ERROR] Failed to execute goal on project ignite-spark_2.10: Could not
>> > resolve dependencies for project
>> > org.apache.ignite:ignite-spark_2.10:jar:2.3.0-SNAPSHOT: The following
>> > artifacts could not be resolved:
>> > org.apache.ignite:ignite-core:jar:2.3.0-SNAPSHOT,
>> > org.apache.ignite:ignite-core:jar:tests:2.3.0-SNAPSHOT,
>> > org.apache.ignite:ignite-indexing:jar:2.3.0-SNAPSHOT: Could not find
>> > artifact org.apache.ignite:ignite-core:jar:2.3.0-SNAPSHOT in
>> > h2database.com
>> > (http://h2database.com/m2-repo) -> [Help 1]
>> >
>> > Maybe it's worth taking a look.
>> > Cheers.
>> >
>> > --ManuelMourato
>> >
>> >
>> >
>> > --
>> > Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>> >
>>
>
>
>
> --
> Nikolay Izhikov
> nizhikov@gmail.com
>



-- 
Nikolay Izhikov
nizhikov@gmail.com

Re: Welcome message

[Alexey Kuznetsov]

Hi,

I granted contributor access for you in JIRA.

Looking forward for your contributions!


On Wed, Nov 8, 2017 at 9:49 PM, Kirill Shirokov 
wrote:

> Dear Ignite Community,
>
> My name is Kirill Shirokov and I would like to make contributions to Apache
> Ignite.
>
> Would it be possible to access Apache Ignite JIRA? My user name is
> 'kirill.shirokov'.
>
> Thank you in advance!
>
> Kind regards,
> Kirill
>



-- 
Alexey Kuznetsov

Re: Conflicting cross-version suffixes in: org.scalatest:scalatest, com.twitter:chill, org.apache.spark:spark-unsafe, org.apache.spark:spark-tags

[Denis Mekhanikov]

Igniters,

I noticed a problem in POM files of *ignite-spark* and *ignite-spark_2.10*
 modules.

*ignite-spark* is targeted to be used by Scala 2.11, while
*ignite-spark_2.10* is made for Scala 2.10.
*But, **ignite-spark* has *spark-unsafe_2.10* as a dependency, and
*ignite-spark_2.10* depends on *json4s-core_2.11*.
It results in that when you add *ignite-spark *module as a dependency to
your SBT project, it stops compiling with the following error:
Modules were resolved with conflicting cross-version suffixes

Nikolay Izhikov, Valentin Kulichenko, can you comment on this? Is it some
kind of a hack, or these dependencies are just specified by mistake?
There is a ticket for this issue:
https://issues.apache.org/jira/browse/IGNITE-6369

Denis

пт, 6 окт. 2017 г. в 16:44, manuelmourato :

> Hi, thank you for taking an interest in this bug.
> I managed to compile my project successfully by taking Val's suggestion,
> changing this:
>
> 
> org.json4s
> json4s-core_2.10
> 3.5.0
> 
>
> I noticed that I couldn't compile using ignite version 2.3, I had to
> downgrade to 2.2, otherwise this error would show up:
>
> [ERROR] Failed to execute goal on project ignite-spark_2.10: Could not
> resolve dependencies for project
> org.apache.ignite:ignite-spark_2.10:jar:2.3.0-SNAPSHOT: The following
> artifacts could not be resolved:
> org.apache.ignite:ignite-core:jar:2.3.0-SNAPSHOT,
> org.apache.ignite:ignite-core:jar:tests:2.3.0-SNAPSHOT,
> org.apache.ignite:ignite-indexing:jar:2.3.0-SNAPSHOT: Could not find
> artifact org.apache.ignite:ignite-core:jar:2.3.0-SNAPSHOT in
> h2database.com
> (http://h2database.com/m2-repo) -> [Help 1]
>
> Maybe it's worth taking a look.
> Cheers.
>
> --ManuelMourato
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

[GitHub] ignite pull request #3003: IGNITE-6762: SparseDistributedMatrixExample faile...

[ybabak]

GitHub user ybabak opened a pull request:

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

IGNITE-6762: SparseDistributedMatrixExample failed with NPE.

Fixed.

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

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

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

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


commit 51cae84a705042e123a063ef0e32d6e1b910
Author: Yury Babak 
Date:   2017-11-03T13:01:39Z

IGNITE-6762: SparseDistributedMatrixExample failed with NPE.
Fixed.




---

Welcome message

[Kirill Shirokov]

Dear Ignite Community,

My name is Kirill Shirokov and I would like to make contributions to Apache
Ignite.

Would it be possible to access Apache Ignite JIRA? My user name is
'kirill.shirokov'.

Thank you in advance!

Kind regards,
Kirill

[GitHub] ignite pull request #3002: Ignite 2.1 master

[apopovgg]

GitHub user apopovgg opened a pull request:

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

Ignite 2.1 master



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

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

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

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


commit afad8e0fc58160f7876925dc6c3051be7a168155
Author: Ilya Lantukh 
Date:   2017-08-23T09:18:44Z

Muted hanging test.

commit ad38f7b4b5e6845b2d7eb888f805484504f5
Author: Ilya Lantukh 
Date:   2017-08-23T11:12:42Z

gg-12662 : Fixed JDBC backward compatibility.

commit 28c906e3e0c51e6f1a4a95b2027d248f9b5035c2
Author: Sergey Chugunov 
Date:   2017-08-02T15:14:46Z

IGNITE-5542 CacheGroup configuration from cluster is merged with local 
settings

(cherry picked from commit 88818ec)

commit caeb11936fa3534b9468d443c11744362044cae5
Author: sboikov 
Date:   2017-08-23T12:19:52Z

ignite-6124 Guard logging with isInfoEnabled

(cherry picked from commit bebe4d8)

commit 6f407ebabb9dc27459fdbee6423640132b995b1d
Author: tledkov-gridgain 
Date:   2017-08-23T12:46:23Z

IGNITE-6169: Fixed thin JDBC driver compatibility problem.

commit 9dac636c4eef494fe612389c19218eec92057fc0
Author: Ilya Kasnacheev 
Date:   2017-08-23T13:26:58Z

IGNITE-4643: Fixed NPE in  JdbcDatabaseMetadata.getIndexInfo(). This closes 
#2481.

commit 77241cdc45c90ee9bab4a7a0f3d5a1a7664e3426
Author: sboikov 
Date:   2017-08-23T13:45:34Z

Merge remote-tracking branch 'community/ignite-2.1.4' into ignite-2.1.4

commit a5e376f63886696331e5be0c457dc0624c49e3d4
Author: sboikov 
Date:   2017-08-23T13:44:04Z

ignite-6124 Added missed initialization of merged join exchanges in 
GridDhtPartitionsExchangeFuture.onBecomeCoordinator

(cherry picked from commit 0c5dca9)

commit be5589db9e0600b295b745ddab5e7aae390ac7ae
Author: Ilya Lantukh 
Date:   2017-08-23T14:25:33Z

ignite-5986 : Fixed failing .NET test.

commit 43e4ff2c0ecd1ef30d18cf1fbc9052f5ba703d05
Author: sboikov 
Date:   2017-07-18T14:52:51Z

Fixed test IgniteClusterActivateDeactivateTestWithPersistence.

(cherry picked from commit 54585ab)

commit d596b7806db3f002f83da5a02bc882d03dae3dfd
Author: Ilya Lantukh 
Date:   2017-08-23T15:23:06Z

Updated classnames.properties.

commit 3e08cd401d598a34832e72afc5e6c94a3a9ab081
Author: sboikov 
Date:   2017-08-23T15:29:52Z

ignite-6174 Temporary changed test until issue not fixed

(cherry picked from commit 4fe8f76)

commit 44e0b4cd62142dce8cf39f826449b9a04e22e1cf
Author: Alexey Kuznetsov 
Date:   2017-08-24T07:57:36Z

IGNITE-6136 Fixed version for demo.
(cherry picked from commit e1bf8d7)

commit 8d1838b03d6c1e5f86dfbb7f41c59895775e20c1
Author: Dmitry Pavlov 
Date:   2017-07-27T11:51:25Z

Adjusted memory policy to prevent OOM.

commit a3ec54b16bce1a569fbefba17188ccb4702b82a4
Author: sboikov 
Date:   2017-08-24T11:09:12Z

ignite-6124 DataStreamerImpl: do not wait for exchange future inside cache 
gateway.

(cherry picked from commit 3ab523c)

commit 30e6d019a21f4a045a50d7d95a04507e3b646e69
Author: sboikov 
Date:   2017-08-24T11:10:34Z

Merge remote-tracking branch 'community/ignite-2.1.4' into ignite-2.1.4

commit 41f574a7372ffc04b69809298798f24fb34c161f
Author: Dmitriy Govorukhin 
Date:   2017-08-24T12:58:27Z

Fixed test.

commit 943736b36d67381157fc2807cd7af4b03d44fef3
Author: nikolay_tikhonov 
Date:   2017-08-24T15:58:16Z

Revert "IGNITE-5947 Fixed "ClassCastException when two-dimensional array is 
fetched from cache".
* Due to this changes break compatibility with .NET;
* This fix doesn't cover all cases.

Signed-off-by: nikolay_tikhonov 

commit c2e836b5b9b183404f4507c64c13ab5c05653d24
Author: EdShangGG 
Date:   2017-08-24T16:15:24Z

ignite-6175 JVM Crash in Ignite Binary Objects Simple Mapper Basic suite

Signed-off-by: Andrey Gura 

commit b2b596b4f59bcf7a1b7397a6fd681a0ae47092db
Author: Andrey Novikov 
Date:   2017-08-25T03:48:15Z

IGNITE-5200 Web Console: Don't cache generated chunks in production.
(cherry picked from commit e1eb1b9)

commit 9399610d2dd4b67b1da6475ce2141787fb8dbb0e
Author: Ilya Lantukh 
Date:   2017-08-25T10:12:32Z

[jira] [Created] (IGNITE-6844) Additional JMX metrics for cluster monitoring.

[Pavel Pereslegin (JIRA)]

Pavel Pereslegin created IGNITE-6844:


 Summary: Additional JMX metrics for cluster monitoring.
 Key: IGNITE-6844
 URL: https://issues.apache.org/jira/browse/IGNITE-6844
 Project: Ignite
  Issue Type: Improvement
  Security Level: Public (Viewable by anyone)
Reporter: Pavel Pereslegin
Assignee: Pavel Pereslegin


For some monitoring tasks we need to access these metrics through JMX:

1. Total server nodes in cluster.
2. Current topology version.

We can’t access them via JMX for now



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] ignite pull request #3001: IGNITE-6840

[devozerov]

GitHub user devozerov opened a pull request:

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

IGNITE-6840



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

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

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

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


commit bd4a151c548b9b0ecbee50d1bfd97e2b7724b1d6
Author: devozerov 
Date:   2017-11-08T07:44:55Z

Create index without unnecessary classes.

commit 9b4c5955f83a395f1a7db9e98de76c77ecdf7793
Author: devozerov 
Date:   2017-11-08T08:03:33Z

Tests.

commit ee602d25cfe75143807e7304cf0e9f2b5721eb96
Author: devozerov 
Date:   2017-11-08T14:27:13Z

Merge branch 'master' into ignite-6840

commit b2b73297c66106918ec9b2188f92bea52b3dbeb9
Author: devozerov 
Date:   2017-11-08T14:34:17Z

Finalization.




---

[jira] [Created] (IGNITE-6843) SQL: optionally do not use WAL when executing CREATE INDEX

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-6843:
---

 Summary: SQL: optionally do not use WAL when executing CREATE INDEX
 Key: IGNITE-6843
 URL: https://issues.apache.org/jira/browse/IGNITE-6843
 Project: Ignite
  Issue Type: Task
  Security Level: Public (Viewable by anyone)
  Components: sql
Affects Versions: 2.3
Reporter: Vladimir Ozerov
 Fix For: 2.4


When index is being created through {{CREATE INDEX}} command, every single 
index update is written to WAL. Let's introduce special mode where updates are 
not written to WAL:
1) Index updates are not written to WAL
2) When index is ready, force checkpoint and wait for it to happen
3) Purge index data if node crashed before checkpoint

Alternatively, we may even not trigger a checkpoint, hoping that that node will 
not crash before the nearest checkpoint is finished. If node crashed during 
this time window, index should be marked as "invalid", and not used for 
queries. Then user should either re-create or rebuild it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Request for contributors permissions

[Anton Vinogradov]

Hi,

Added you to the contributors list. Please go ahead and assign the tickets
on yourself.

On Wed, Nov 8, 2017 at 4:20 PM, Alex Plehanov 
wrote:

> Hello Ignite Community!
>
>
> My name is Aleksey. I want to contribute to Apache Ignite and want to start
> with implementation of some JMX metrics. Please add me as contributor.
>
> My account in JIRA is "alex_pl".
>
>
> Thanks!
>

Request for contributors permissions

[Alex Plehanov]

Hello Ignite Community!


My name is Aleksey. I want to contribute to Apache Ignite and want to start
with implementation of some JMX metrics. Please add me as contributor.

My account in JIRA is "alex_pl".


Thanks!

[GitHub] ignite pull request #2999: Fixed licensed header

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #3000: ignite-6767: reset of the topVer on loading of th...

[sk0x50]

GitHub user sk0x50 opened a pull request:

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

ignite-6767: reset of the topVer on loading of the entry



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

$ git pull https://github.com/sk0x50/ignite ignite-6767-master

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

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


commit b3d451491ae14ce6b031d5dacaf23f06448011fc
Author: Slava Koptilin 
Date:   2017-11-08T12:39:15Z

ignite-6767: reset of the topVer on loading of the entry




---

[GitHub] ignite pull request #2999: Fixed licensed header

[vldpyatkov]

GitHub user vldpyatkov opened a pull request:

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

Fixed licensed header



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

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

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

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


commit cee55afd0079e87a76b3144d2fac4edef3f81645
Author: vd-pyatkov 
Date:   2017-11-08T12:32:14Z

Fixed licensed header




---

Re: Add new JMX metrics.

[Pavel Pereslegin]

Yakov, thanks for your suggestion.

I will create such MBean to include these metrics.

2017-11-07 20:11 GMT+03:00 Yakov Zhdanov :
> This seems to be incorrect place for implementing it. I would think of
> something more generic like IgniteClusterMBean. It should also work for any
> implementation of discovery SPI if one ever appears =)
>
> --Yakov

[jira] [Created] (IGNITE-6842) Stop all nodes after test by default.

[Alexei Scherbakov (JIRA)]

Alexei Scherbakov created IGNITE-6842:
-

 Summary: Stop all nodes after test by default.
 Key: IGNITE-6842
 URL: https://issues.apache.org/jira/browse/IGNITE-6842
 Project: Ignite
  Issue Type: Improvement
  Security Level: Public (Viewable by anyone)
Reporter: Alexei Scherbakov


Currently it's required to manually call stopAllGrids() after test completion.

This leads to errors in subsequent tests if someone forgets to call it and to 
additional boilerplate code in tests.

Right choice is to make this default behavior.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] ignite pull request #2983: Ignite 12992

[ntikhonov]

Github user ntikhonov closed the pull request at:

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


---

Re: GA Grid: Request to contribute GA library to Apache Ignite

[techbysample]

Denis/Yury,

I updated my previous post slightly, 
For clarity, Please simply respond to this post and disregard previous.

Upon review of your previous comments,  please respond to my feedback :
 
1.  I believe GA Grid can be implemented in separate package within ML
library and operate independently  of other algorithms for use cases where
/only /GA is required.

2.   I am still not totally clear concerning Trainer and Model relationship
in the ML API.

 a. Since org.apache.ignite.ml.Trainer and
org.apache.ignite.ml.Model
are not available, when is it planned to be available? 

  Please advise when available.

 b.  Based on  Yury's comments:
 
"...For both concepts we have API: org.apache.ignite.ml.Model and
org.apache.ignite.ml.Trainer. So if we want to use genetic algoritm for
model trainig we should implement specific trainer for each ML algorithms
like lin regression, kmean, decision tree and others.

For example let`s take a look on lin regression. Currently we have OLS
(Ordinary Least Squares) multiple linear regression. For this regression we
will have OLSRegressionModel and at least two possible trainers: analytical
trainer (a solution of matrix equation, analytical solution) and gradient
descent (numerical solution). And also we could implement GA trainer which
will use GA Grid... "

Do org.apache.ignite.ml.Trainer generate org.apache.ignite.ml.Models?
This part is still not clear..

  Please advise and clarify accordingly.


Best,
Turik 



--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

[GitHub] ignite pull request #2998: Ignite-gg-13021

[AMashenkov]

GitHub user AMashenkov opened a pull request:

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

Ignite-gg-13021

Fixed possible NPE on node stop.

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

$ git pull https://github.com/gridgain/apache-ignite ignite-gg-13021-master

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

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


commit f874ee78e8dfee1a1389d825dd0c621a208452f1
Author: Andrey V. Mashenkov 
Date:   2017-11-08T09:12:05Z

GG-13021: Fixed NPE on node stop when SSL is used.




---

[GitHub] ignite pull request #2997: IGNITE-6835 ODBC driver should handle ungraceful ...

[apopovgg]

GitHub user apopovgg opened a pull request:

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

IGNITE-6835 ODBC driver should handle ungraceful tcp disconnects



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

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

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

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


commit dd595013ea42af8f5c60a3a8f5ea7a6c7b9c8e7e
Author: apopov 
Date:   2017-11-08T11:42:59Z

IGNITE-6835 ODBC driver should handle ungraceful tcp disconnects




---

[GitHub] ignite pull request #2996: BaselineAffinityTopology

[sergey-chugunov-1985]

GitHub user sergey-chugunov-1985 opened a pull request:

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

BaselineAffinityTopology



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

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

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

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


commit 174cfa71919e2825e0a76550123c00491bbc2a15
Author: Ilya Lantukh 
Date:   2017-09-26T12:58:18Z

ignite-5852 : Introduced BaselineTopology mechanics.

commit e091521af4e24c1c39e785e797de7fc61eeea22f
Author: Ilya Lantukh 
Date:   2017-10-06T15:24:19Z

ignite-5852 : Reverted eqNodes(...) to use uuid, added uuid generation for 
detached nodes.

commit a0cd8254fbd754e63a7b81945b97e752a250a921
Author: Ilya Lantukh 
Date:   2017-10-06T17:06:12Z

ignite-5852 : Fixed affinity calculation for local cache.

commit 626d7ea877f9e7c0f425ea4fbf67df2ab00e7bcc
Author: Ilya Lantukh 
Date:   2017-10-18T13:47:40Z

ignite-5852 : Fixed multiple calls of onActivate/onDeActivate callbacks 
when BLT is changed.

commit 8c91aaec7716cc97089a784a11e733600f9f682c
Author: Ilya Lantukh 
Date:   2017-10-18T13:52:22Z

ignite-5852 : Fixed multiple calls of onActivate/onDeActivate callbacks 
when BLT is changed.

commit 2bffce366a6caf50ce3d931dbcb13a5d00cb74d0
Author: Ilya Lantukh 
Date:   2017-10-20T13:52:46Z

ignite-5852 : Node filter handling.

commit d8d141de54d2e752bd6de2977952bfefc9588392
Author: Ilya Lantukh 
Date:   2017-10-20T14:20:54Z

ignite-5852 : Tests for auto-activation.

commit 6a1d8874b6d1d203992b53ef7257beae02271203
Author: Ilya Lantukh 
Date:   2017-10-24T11:51:12Z

ignite-5852 : Conflict resolution.

commit 829da8deff747267e8737dc90a55470d1885799d
Author: Konstantin Dudkov 
Date:   2017-08-17T10:39:28Z

IGNITE-5849 refactor DataPageIO & FreeList, introduce MetaStorage

commit ec6748684793a162fd34303b381a98ec4be6ac12
Author: Ilya Lantukh 
Date:   2017-10-24T14:12:02Z

Merge branches 'ignite-5849-2' and 'ignite-blt' of 
https://github.com/gridgain/apache-ignite into ignite-blt

commit 4774009eca2b4ea33e333747240e93ca86ae3ce5
Author: Ilya Lantukh 
Date:   2017-10-24T16:12:33Z

Metastore integration : WIP.

commit 7654b6f45b3f02fd51f3bf5c7fb514b121a7dc64
Author: Ilya Lantukh 
Date:   2017-10-25T13:59:39Z

Metastore integration : WIP.

commit 6a8d8ff85cd2f9a0c427ca7858faa0f9937c57b3
Author: Ilya Lantukh 
Date:   2017-10-25T15:21:34Z

Test for possible issue when primary node leaves and returns.

commit 9538afc339c6dd7d2a0ade758e339075528d2a3f
Author: Ilya Lantukh 
Date:   2017-10-25T15:24:23Z

Added TODO.

commit cfdd4f2d32a5ce7e637a8f7564725b1f093b7b7d
Author: Ilya Lantukh 
Date:   2017-10-25T16:14:07Z

Added test.

commit 5220672fcc42175ac448e91d54db12b4e7e7d128
Author: Ilya Lantukh 
Date:   2017-10-26T15:17:02Z

Updated test to use auto-activation.

commit 29758238a9562f27a6fb16993c0a24661833e7a6
Author: Sergey Chugunov 
Date:   2017-10-27T09:56:08Z

IGNITE-6281 simple validation of BaselineHistory was added

commit b4894027ac43a0b8ad098a5d114f2d9780b0136f
Author: Sergey Chugunov 
Date:   2017-10-27T10:40:02Z

IGNITE-6281 compilation error fixed

commit d7b720fc378a163210068b7d63efaea4667128bc
Author: Ilya Lantukh 
Date:   2017-10-27T12:46:17Z

Minor fixes.

commit af3968cabcb6a0704de708fffb88cafb30548bf6
Author: Ilya Lantukh 
Date:   2017-10-27T15:09:55Z

Minor fixes.

commit 6efb54c924178537b0fbe7788f6946edec55488d
Author: Ilya Lantukh 
Date:   2017-10-27T16:32:07Z

Metastore durability = WIP.

commit 13fa84f007fef8299c1d5ace1d4517a2f5f2a048
Author: Sergey Chugunov 
Date:   2017-10-31T11:52:17Z

Responsibilities for reading/writing BaselineTopology were moved to 
ClusterStateProcessor, new test was added

commit 0e443a45eb32e060a6180b81e978c54699c375b9
Author: Alexey Goncharuk 
Date:   2017-11-03T11:33:25Z

Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/ignite 
into ignite-blt-merge

commit 375645817f3a193fe13a07e836e4d42fd0f74819
Author: Ilya Lantukh 
Date:   2017-11-01T14:12:02Z

Fixed metastore initialization.

commit 77ff8550175c25527d79143fecd883a95aa598b5
Author: Sergey Chugunov 

[GitHub] ignite pull request #2995: IGNITE-6841: Increased ODBC protocol version for ...

[isapego]

GitHub user isapego opened a pull request:

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

IGNITE-6841: Increased ODBC protocol version for multiple statements.



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

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

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

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


commit 9feae7a5f6be5de66ee22b360050dc720974f5f6
Author: Igor Sapego 
Date:   2017-11-08T10:40:29Z

IGNITE-6841: Increased ODBC protocol version for multiple statements




---

[jira] [Created] (IGNITE-6841) ODBC: Add new version for multiple result set functionality

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-6841:
---

 Summary: ODBC: Add new version for multiple result set 
functionality
 Key: IGNITE-6841
 URL: https://issues.apache.org/jira/browse/IGNITE-6841
 Project: Ignite
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
  Components: odbc
Affects Versions: 2.3
Reporter: Igor Sapego
Assignee: Igor Sapego
 Fix For: 2.4


Changes made in IGNITE-6357 changed ODBC protocol, but protocol version was not 
increased. Need to fix it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] ignite pull request #2994: WebSessionFilter can handle liberty session ids

[andreaswe]

GitHub user andreaswe opened a pull request:

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

WebSessionFilter can handle liberty session ids

## Problem:
Websphere Liberty creates session ids in the following form (way the 
session id is serialized in the cookie):
\\:\ 
e.g. 3XeX_c5NHR5fJLYufFzt5ka:a3e94cfd-b391-4d9b-b9e7-6ddfcbf8c334

If a request is received by the same instance where the session was 
created, the requested session id is only the \ part.
If a request is received by the another instance, the requested session id 
is the complete 
\\:\

Because of this behavior, Ignite searches for 
\\:\ in the cache, but only \ was stored. 

## Solution:
Implement a sessionIdTransformer for Websphere Liberty that normalizes 
\\:\ to \


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

$ git pull https://github.com/andreaswe/ignite master

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

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


commit 1ef4cb11337e22324fa11a0ba599e5cb9df0315d
Author: extern-weber-andreas 
Date:   2017-11-08T08:49:24Z

WebSessionFilter can handle liberty session ids




---

[GitHub] ignite pull request #2934: IGNITE-6737

[asfgit]

Github user asfgit closed the pull request at:

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


---