Re: Ignite contibutors page

[Aleksei Zaitsev]

Hello Denis,

Could you, please, add me to the list too: alexzaitzev (Aleksei Zaitsev).
https://ignite.apache.org/community/resources.html 
Thanks.

Best regards,
Alex.



15.03.2018, 21:03, "Denis Magda" :
> Dmitriy, Alexey,
>
> Done, now your names are engraved on the page ;)
>
> --
> Denis
>
> On Thu, Mar 15, 2018 at 2:34 AM, Dmitriy Shabalin 
> wrote:
>
>>  I'm not mentioned on the community contributors page:
>>  https://ignite.apache.org/community/resources.html
>>
>>  pls add me, dmitriyff (Dmitriy Shabalin)
>>
>>  --
>>  Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

Re: IgniteConfiguration, TcpDiscoverySpi, TcpCommunicationSpi timeouts

[Valentin Kulichenko]

Hi Stan,

I'm 100% for this activity, however I don't think we should change the
behavior of timeouts you listed in #2 - this can lead to unexpected
behavior for users who already use them. I would just deprecate them and
eventually remove.

-Val

On Mon, May 28, 2018 at 1:29 PM, Stanislav Lukyanov 
wrote:

> Hi folks,
>
> It looks like we stopped half-way with this activity. I’d like to pick it
> up.
>
> All seem to agree that we should simplify the timeout settings.
> Here are the specific actions I’d like to propose:
>
> 1. Promote the use of global timeouts as the best practice
> *What*: update the docs to encourage users to rely on the following
> timeouts for their “network stability” settings
> IgniteConfiguration.failureDetectionTimeout
> IgniteConfiguration.clientFailureDetectionTimeout
> IgniteConfiguration.networkTimeout
> *When*: update readme.io docs for 2.5 and Javadoc for 2.6
>
> 2. Discourage the use of finer timeouts
> *What*:
> - update the docs to discourage users to use the following timeouts and
> announce their upcoming deprecation and removal
> TcpDiscoverySpi.socketTimeout
> TcpDiscoverySpi.ackTimeout
> TcpDiscoverySpi.maxAckTimeout
> TcpDiscoverySpi.reconnectCount
> TcpCommunicationSpi.connectTimeout
> TcpCommunicationSpi.maxConnectTimeout
> TcpCommunicationSpi.reconnectCount
> - deprecate the properties in code
> - remove the properties in code
> *When*:
> - readme.io update with deprecation announcement for 2.5
> - @Deprecated in code + Javadoc update + respective readme.io rewording
> for 2.6
> - properties removal in 3.0
>
> 3. Make “orphan” timeouts rely on global timeouts, then deprecate and
> remove
> *What*:
> Two settings currently don’t default to the global equivalents, although
> they should:
> - TcpCommunicationSpi.socketWriteTimeout should default to
> failureDetectionTimeout
> - TcpDiscoverySpi.networkTimeout should default to IgniteConfiguration.
> networkTImeout
> So the course of action would be:
> - update the docs to explain that these timeouts have to be used for now,
> but announce their upcoming deprecation and removal
> - change the properties to default to their global counterparts and
> deprecate them in code
> - remove the properties in code
> *When*:
> - readme.io update with deprecation announcement for 2.5
> - changing defaults + @Deprecated in code + Javadoc update + respective
> readme.io rewording for 2.6
> - properties removal in 3.0
>
> 4. Don’t touch other timeouts
> Other timeouts, like TcpDiscoverySpi.joinTimeout or 
> TcpCommunicationSpi.idleConnectionTimeout,
> are orthogonal to the whole
> “network stability” theme discussed above, and don’t have to be changed.
>
> Finally, I’ve prepared a draft of the docs page that may be used as a base
> for the readme.io update.
> This email is pretty long already, so please find the draft attached to
> the JIRA issue
> https://issues.apache.org/jira/browse/IGNITE-7704.
>
> Please share your thoughts.
>
> Thanks,
> Stan
>
> From: Alexey Popov
> Sent: 1 марта 2018 г. 17:01
> To: dev@ignite.apache.org
> Subject: IgniteConfiguration, TcpDiscoverySpi, TcpCommunicationSpi timeouts
>
> Hi Igniters,
>
> We often see similar questions from users and customers related to
> IgniteConfiguration, TcpDiscoverySpi, TcpCommunicationSpi timeouts and
> their
> relations. And we see several side-effects after incorrect timeout
> configuration.
>
> I tried to briefly describe these timeout settings (please see below) and
> found out that the most of them do not have sense in terms of cluster
> functions/operations and could not be explained to the users.
>
> I propose to deprecate most of them and leave only the timeouts we can
> explain in common terms ( (setFailureDetectionTimeout, setNetworkTimeout,
> setJoinTimeout and some others).
>
> Please let me know your thoughts.
>
> Thanks,
> Alexey
>
> GLOBAL:
>
> IgniteConfiguration.setNetworkTimeout:
> It is a global timeout for high-level operations where a network is
> involved. For instance, IgniteMessaging delivery uses this timeout or
> DiscoverySpi handshake.
>
> IgniteConfiguration.setFailureDetectionTimeout:
> It is a global timeout for detecting failures at IgniteSpi implementations
> (including DiscoverySpi and CommunicationSpi).
> The failure detection algorithm actually limits a range of simple network
> operations related to a single logical operation (for instance, a reliable
> delivery of some DiscoverySpi message within a cluster).
> Failure detection timeout is a cumulative timeout for a socket connection,
> sending and receiving data bytes and all possible socket retries (if some
> failure happens).
> This timeout is intended to simplify the failure detection condition from a
> user perspective.
>
> IgniteConfiguration.setClientFailureDetectionTimeout: - it is a special
> case
> for DiscoverySpi client-node Ignite.
>
> TCP DISCOVERY SPI:
>
> If you need more control over failure detection algorithm for
> TcpDiscoverySpi you can explicitly use the following 

Re: Platform .NET add to RunAll Basic suite

[Dmitry Pavlov]

Hi Pavel,

Thank you for pointing to this. We've noticed that, and Ilya K. has already
prepared the fix,
https://issues.apache.org/jira/browse/IGNITE-8604
https://github.com/apache/ignite/pull/4072

If you have some time you can apply the PR, or I will merge it later.

Sincerely,
Dmitriy Pavlov

пн, 28 мая 2018 г. в 23:45, Pavel Tupitsyn :

> Hi Dmirty,
>
> IGNITE-5789 merge [1] introduces this bug:
>
> Additional cache is being started from a template (cache name ends with *).
> Normally template caches are only started when a cache with matching name
> has been requested.
>
> Pavel
>
> [1]
>
> https://github.com/apache/ignite/commit/d821d0999749a1be318a2106d736542272a42ab0
>
> On Fri, May 25, 2018 at 8:23 PM, Dmitriy Setrakyan  wrote:
>
> > Hi Pavel, can you please respond here?
> >
> > -- Forwarded message --
> > From: Dmitry Pavlov 
> > Date: Fri, May 25, 2018 at 5:08 AM
> > Subject: Platform .NET add to RunAll Basic suite
> > To: dev 
> >
> >
> > Hi Igniters,
> >
> > recently we've got 60-70 new test failures in .NET
> >
> > For me it is not simple to say which commit has failed build, so I
> suggest
> > the following:
> >
> > 1. Add Platform .NET tests to run-all basic, it will be started by
> > per-VCS-commit basis. Per commit run will indicate change which failed
> the
> > build.
> >
> > 2. Find out and mute flaky tests with tickets (if any).
> >
> > WDYT?
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> >
>

Re: Platform .NET add to RunAll Basic suite

[Pavel Tupitsyn]

Hi Dmirty,

IGNITE-5789 merge [1] introduces this bug:

Additional cache is being started from a template (cache name ends with *).
Normally template caches are only started when a cache with matching name
has been requested.

Pavel

[1]
https://github.com/apache/ignite/commit/d821d0999749a1be318a2106d736542272a42ab0

On Fri, May 25, 2018 at 8:23 PM, Dmitriy Setrakyan  wrote:

> Hi Pavel, can you please respond here?
>
> -- Forwarded message --
> From: Dmitry Pavlov 
> Date: Fri, May 25, 2018 at 5:08 AM
> Subject: Platform .NET add to RunAll Basic suite
> To: dev 
>
>
> Hi Igniters,
>
> recently we've got 60-70 new test failures in .NET
>
> For me it is not simple to say which commit has failed build, so I suggest
> the following:
>
> 1. Add Platform .NET tests to run-all basic, it will be started by
> per-VCS-commit basis. Per commit run will indicate change which failed the
> build.
>
> 2. Find out and mute flaky tests with tickets (if any).
>
> WDYT?
>
> Sincerely,
> Dmitriy Pavlov
>
>

RE: IgniteConfiguration, TcpDiscoverySpi, TcpCommunicationSpi timeouts

[Stanislav Lukyanov]

Hi folks,

It looks like we stopped half-way with this activity. I’d like to pick it up.

All seem to agree that we should simplify the timeout settings.
Here are the specific actions I’d like to propose:

1. Promote the use of global timeouts as the best practice
*What*: update the docs to encourage users to rely on the following timeouts 
for their “network stability” settings
IgniteConfiguration.failureDetectionTimeout
IgniteConfiguration.clientFailureDetectionTimeout 
IgniteConfiguration.networkTimeout
*When*: update readme.io docs for 2.5 and Javadoc for 2.6

2. Discourage the use of finer timeouts
*What*:
- update the docs to discourage users to use the following timeouts and 
announce their upcoming deprecation and removal
TcpDiscoverySpi.socketTimeout
TcpDiscoverySpi.ackTimeout
TcpDiscoverySpi.maxAckTimeout
TcpDiscoverySpi.reconnectCount
TcpCommunicationSpi.connectTimeout
TcpCommunicationSpi.maxConnectTimeout
TcpCommunicationSpi.reconnectCount
- deprecate the properties in code
- remove the properties in code
*When*:
- readme.io update with deprecation announcement for 2.5
- @Deprecated in code + Javadoc update + respective readme.io rewording for 2.6
- properties removal in 3.0

3. Make “orphan” timeouts rely on global timeouts, then deprecate and remove
*What*:
Two settings currently don’t default to the global equivalents, although they 
should:
- TcpCommunicationSpi.socketWriteTimeout should default to 
failureDetectionTimeout
- TcpDiscoverySpi.networkTimeout should default to 
IgniteConfiguration.networkTImeout
So the course of action would be:
- update the docs to explain that these timeouts have to be used for now, but 
announce their upcoming deprecation and removal
- change the properties to default to their global counterparts and deprecate 
them in code
- remove the properties in code
*When*:
- readme.io update with deprecation announcement for 2.5
- changing defaults + @Deprecated in code + Javadoc update + respective 
readme.io rewording for 2.6
- properties removal in 3.0

4. Don’t touch other timeouts
Other timeouts, like TcpDiscoverySpi.joinTimeout or 
TcpCommunicationSpi.idleConnectionTimeout, are orthogonal to the whole
“network stability” theme discussed above, and don’t have to be changed.

Finally, I’ve prepared a draft of the docs page that may be used as a base for 
the readme.io update.
This email is pretty long already, so please find the draft attached to the 
JIRA issue 
https://issues.apache.org/jira/browse/IGNITE-7704.

Please share your thoughts.

Thanks,
Stan

From: Alexey Popov
Sent: 1 марта 2018 г. 17:01
To: dev@ignite.apache.org
Subject: IgniteConfiguration, TcpDiscoverySpi, TcpCommunicationSpi timeouts

Hi Igniters,

We often see similar questions from users and customers related to
IgniteConfiguration, TcpDiscoverySpi, TcpCommunicationSpi timeouts and their
relations. And we see several side-effects after incorrect timeout
configuration.

I tried to briefly describe these timeout settings (please see below) and
found out that the most of them do not have sense in terms of cluster
functions/operations and could not be explained to the users.

I propose to deprecate most of them and leave only the timeouts we can
explain in common terms ( (setFailureDetectionTimeout, setNetworkTimeout,
setJoinTimeout and some others).

Please let me know your thoughts.

Thanks,
Alexey

GLOBAL:

IgniteConfiguration.setNetworkTimeout:
It is a global timeout for high-level operations where a network is
involved. For instance, IgniteMessaging delivery uses this timeout or
DiscoverySpi handshake.

IgniteConfiguration.setFailureDetectionTimeout:
It is a global timeout for detecting failures at IgniteSpi implementations
(including DiscoverySpi and CommunicationSpi).
The failure detection algorithm actually limits a range of simple network
operations related to a single logical operation (for instance, a reliable
delivery of some DiscoverySpi message within a cluster).
Failure detection timeout is a cumulative timeout for a socket connection,
sending and receiving data bytes and all possible socket retries (if some
failure happens). 
This timeout is intended to simplify the failure detection condition from a
user perspective.

IgniteConfiguration.setClientFailureDetectionTimeout: - it is a special case
for DiscoverySpi client-node Ignite.

TCP DISCOVERY SPI:

If you need more control over failure detection algorithm for
TcpDiscoverySpi you can explicitly use the following low-level options (that
will disable failureDetectoinTimeout logic):

1. TcpDiscoverySpi.setConnectTimeout - socket connection timeout
2. TcpDiscoverySpi.setReconnectCount - number of reconnect attempts used
when establishing connection with the remote node and sending messages to it
3. TcpDiscoverySpi.setSocketTimeout - socket write timeout. The write
operation will be repeated getReconnectCount() times if it exceeds this
timeout
4. TcpDiscoverySpi.setAckTimeout - message acknowledgment timeout. If a
message 

Re: About Apache.Ignite.EntityFramework

[Pavel Tupitsyn]

Hi,

No, there is no Entity Framework Core support for now.

Pavel

On Fri, May 25, 2018 at 10:14 AM, wales wang  wrote:

> Hi, guys:
>
>
>  I want to used Apache.Ignite.EntityFramework in the .net core 2.0,
> but this component does not support .net core 2.0.
>
>
>  Is there a version of.net core 2.0 that will be supported?
>
>
>  Waiting for your reply.
>
>
>  Thanks.
>

[jira] [Created] (IGNITE-8633) Node fails to bail out of wrong BLT, instead hanging around indefinitely

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-8633:
---

 Summary: Node fails to bail out of wrong BLT, instead hanging 
around indefinitely
 Key: IGNITE-8633
 URL: https://issues.apache.org/jira/browse/IGNITE-8633
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.4
Reporter: Ilya Kasnacheev
Assignee: Stanislav Lukyanov


Follow-up on 
https://stackoverflow.com/questions/50234056/how-to-give-multiple-static-ip-in-apache-ignite-cache-configuration-xml-file/50270676?noredirect=1#comment88095814_50270676
 but not quite the same.

I have three nodes: A, B and C.
I've started A and C and performed activation.
Then I stopped them both, started B and performed activation on it.
Now I have two BlT clusters: (A, C) and (B)
However, when I start B; and then try to launch nodes A or C I get inconsistent 
behavior:
When I launch C, I get the error:
{code}
org.apache.ignite.spi.IgniteSpiException: BaselineTopology of joining node 
(8c1e210f-52bb-424f-9c7c-a2e7b1bab546 ) is not compatible with BaselineTopology 
in the cluster. Branching history of cluster BlT ([-1349069127]) doesn't 
contain branching point hash of joining node BlT (631694798). Consider cleaning 
persistent storage of the node and adding it to the cluster again.
{code}

But when I launch A, it never enters topology, but also never fails. Moreover, 
A and B will ping pong each other for eternity:
{code}
[20:16:38,596][WARNING][main][TcpDiscoverySpi] Node has not been connected to 
topology and will repeat join process. Check remote nodes logs for possible 
error messages. Note that large topology may require significant time to start. 
Increase 'TcpDiscoverySpi.networkTimeout' configuration property if getting 
this message on the starting nodes [networkTimeout=5000]
[20:17:29,514][INFO][tcp-disco-srvr-#2][TcpDiscoverySpi] TCP discovery accepted 
incoming connection [rmtAddr=/172.25.1.36, rmtPort=49030]
[20:17:29,522][INFO][tcp-disco-srvr-#2][TcpDiscoverySpi] TCP discovery spawning 
a new thread for connection [rmtAddr=/172.25.1.36, rmtPort=49030]
[20:17:29,523][INFO][tcp-disco-sock-reader-#26][TcpDiscoverySpi] Started 
serving remote node connection [rmtAddr=/172.25.1.36:49030, rmtPort=49030]
[20:17:29,524][INFO][tcp-disco-sock-reader-#26][TcpDiscoverySpi] Received ping 
request from the remote node [rmtNodeId=37104137-a21e-4b6f-a70b-09164300bbfc, 
rmtAddr=/172.25.1.36:49030, rmtPort=49030]
[20:17:29,525][INFO][tcp-disco-sock-reader-#26][TcpDiscoverySpi] Finished 
writing ping response [rmtNodeId=37104137-a21e-4b6f-a70b-09164300bbfc, 
rmtAddr=/172.25.1.36:49030, rmtPort=49030]
[20:17:29,526][INFO][tcp-disco-sock-reader-#26][TcpDiscoverySpi] Finished 
serving remote node connection [rmtAddr=/172.25.1.36:49030, rmtPort=49030
[20:18:30,733][INFO][tcp-disco-srvr-#2][TcpDiscoverySpi] TCP discovery accepted 
incoming connection [rmtAddr=/172.25.1.36, rmtPort=50857]
[20:18:30,733][INFO][tcp-disco-srvr-#2][TcpDiscoverySpi] TCP discovery spawning 
a new thread for connection [rmtAddr=/172.25.1.36, rmtPort=50857]
[20:18:30,733][INFO][tcp-disco-sock-reader-#47][TcpDiscoverySpi] Started 
serving remote node connection [rmtAddr=/172.25.1.36:50857, rmtPort=50857]
[20:18:30,734][INFO][tcp-disco-sock-reader-#47][TcpDiscoverySpi] Received ping 
request from the remote node [rmtNodeId=37104137-a21e-4b6f-a70b-09164300bbfc, 
rmtAddr=/172.25.1.36:50857, rmtPort=50857]
[20:18:30,734][INFO][tcp-disco-sock-reader-#47][TcpDiscoverySpi] Finished 
writing ping response [rmtNodeId=37104137-a21e-4b6f-a70b-09164300bbfc, 
rmtAddr=/172.25.1.36:50857, rmtPort=50857]
[20:18:30,734][INFO][tcp-disco-sock-reader-#47][TcpDiscoverySpi] Finished 
serving remote node connection [rmtAddr=/172.25.1.36:50857, rmtPort=50857
{code}
{code}
[20:16:28,793][INFO][tcp-disco-msg-worker-#3][GridSnapshotAwareClusterStateProcessorImpl]
 Received state change finish message: true
[20:16:28,803][INFO][exchange-worker-#62][time] Finished exchange init 
[topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], crd=true]
[20:16:28,812][INFO][exchange-worker-#62][GridCachePartitionExchangeManager] 
Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion 
[topVer=1, minorTopVer=1], evt=DISCOVERY_CUSTOM_EVT, 
node=37104137-a21e-4b6f-a70b-09164300bbfc]
[20:16:28,818][INFO][sys-#68][GridSnapshotAwareClusterStateProcessorImpl] 
Successfully performed final activation steps 
[nodeId=37104137-a21e-4b6f-a70b-09164300bbfc, client=false, 
topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1]]
[20:16:33,571][INFO][tcp-disco-srvr-#2][TcpDiscoverySpi] TCP discovery accepted 
incoming connection [rmtAddr=/172.25.1.35, rmtPort=42500]
[20:16:33,579][INFO][tcp-disco-srvr-#2][TcpDiscoverySpi] TCP discovery spawning 
a new thread for connection [rmtAddr=/172.25.1.35, rmtPort=42500]
[20:16:33,580][INFO][tcp-disco-sock-reader-#9][TcpDiscoverySpi] Started serving 
remote node connection 

[GitHub] ignite pull request #4082: IGNITE-8628: Expose list of SQL (ODBC\JDBC\Thin) ...

[AMashenkov]

GitHub user AMashenkov opened a pull request:

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

IGNITE-8628: Expose list of SQL (ODBC\JDBC\Thin) clients via JMX.



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

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

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

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


commit b7bd12e278738a542afbdd6361aa211a8fdea83d
Author: Andrey V. Mashenkov 
Date:   2018-05-28T16:58:55Z

IGNITE-8628: Expose list of SQL (ODBC\JDBC\Thin) clients via JMX.




---

[jira] [Created] (IGNITE-8632) Exception in shutdown routine can prevent JVM shutdown

[Anton Kurbanov (JIRA)]

Anton Kurbanov created IGNITE-8632:
--

 Summary: Exception in shutdown routine can prevent JVM shutdown
 Key: IGNITE-8632
 URL: https://issues.apache.org/jira/browse/IGNITE-8632
 Project: Ignite
  Issue Type: Bug
  Components: general
Reporter: Anton Kurbanov
Assignee: Anton Kurbanov
 Fix For: 2.6


The exception like below left node in stopping state fo forever:

java.lang.NullPointerException: null
at 
java.util.concurrent.ConcurrentLinkedQueue.checkNotNull(ConcurrentLinkedQueue.java:914)
at 
java.util.concurrent.ConcurrentLinkedQueue.offer(ConcurrentLinkedQueue.java:327)
at 
java.util.concurrent.ConcurrentLinkedQueue.add(ConcurrentLinkedQueue.java:297)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateResponse.addFailedKey(GridNearAtomicUpdateResponse.java:347)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicSingleUpdateFuture.addFailedKeys(GridDhtAtomicSingleUpdateFuture.java:166)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.onDone(GridDhtAtomicAbstractUpdateFuture.java:446)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.onDone(GridDhtAtomicAbstractUpdateFuture.java:56)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:345)
at 
org.apache.ignite.internal.processors.cache.GridCacheMvccManager.cancelClientFutures(GridCacheMvccManager.java:388)
at 
org.apache.ignite.internal.processors.cache.GridCacheMvccManager.onStop(GridCacheMvccManager.java:370)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStop(GridCacheProcessor.java:956)
at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2095)
at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2041)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2397)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2360)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.run(IgnitionEx.java:1871)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #4081: IGNITE-8122, IGNITE-8339 Backport to 2.4

[Jokser]

GitHub user Jokser opened a pull request:

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

IGNITE-8122, IGNITE-8339 Backport to 2.4



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

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

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

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


commit d1a23c684dfadedf2b28966a223684827f3c5d7b
Author: David Wimsey 
Date:   2018-01-31T08:47:25Z

IGNITE-7576 Scripts: fix version check regexp to handle OpenJDK

This closes #3456

commit c8ce1f66e98b3174d771a3b801a2538499dc2c3d
Author: Ivan Rakov 
Date:   2018-01-31T09:51:09Z

IGNITE-7475 Improved VerifyBackupPartitionsTask to calculate partition 
hashes in parallel - Fixes #3407.

Signed-off-by: Alexey Goncharuk 

commit 258ff4299da20122d7c387cb8579264035c93c18
Author: Alexey Goncharuk 
Date:   2018-01-31T13:52:24Z

IGNITE-7573 Fixed full API tests to be compliant with baseline topology

commit aca3b8c664de8dcbbfeabbb0f8c252194d6ad1b2
Author: Pavel Tupitsyn 
Date:   2018-01-31T16:49:07Z

IGNITE-7473 .NET: Fix ConfigurationManager assembly error on Linux

commit 7bb61dfb1dcbcd759f159618a008bd02f6e6
Author: Alexey Kuznetsov 
Date:   2018-02-01T08:22:53Z

ignite-2.4.0 Update version.

(cherry picked from commit 2e43749)

commit 254ed3a9c32d092702a0461509bf867cbd7cdee6
Author: Alexey Kuznetsov 
Date:   2018-02-01T08:22:53Z

ignite-2.4.0 Update version.

(cherry picked from commit 2e43749)

commit d5782c53b8beab17ea4f953ad009d71b02fc335c
Author: artemmalykh 
Date:   2018-02-01T09:43:02Z

IGNITE-7590: fixed tree example

this closes #3459

(cherry picked from commit a9d40a7)

commit c1a9c0a404d77fba08170bedf14844f87abe3028
Author: Alexey Goncharuk 
Date:   2018-02-01T10:17:28Z

IGNITE-7569 Fixing index rebuild future

commit e43799ce70cdbe03d9e206381d1d5138b820b075
Author: Alexey Goncharuk 
Date:   2018-02-01T13:39:17Z

IGNITE-7520 Provide util-methods to get baseline from context - Fixes #3431.

commit a54bfd1a0906cee8394a0b495f61549ab63e4346
Author: dpavlov 
Date:   2018-02-01T15:31:12Z

IGNITE-7599 Missed licenses in ignite-direct-io module

Signed-off-by: Anton Vinogradov 

(cherry picked from commit d88af9b)
Signed-off-by: Anton Vinogradov 

commit 8f5fc7cfb0624cf2048efad38dfff32f782116e8
Author: Sergey Chugunov 
Date:   2018-02-02T08:24:29Z

IGNITE-7580 Fix compatibilityMode flag consistency

This closes #3466

(cherry picked from commit 8f2045e)

commit d3ddd50cb2b889173176b6c47c9ff61410e1d909
Author: Ilya Lantukh 
Date:   2018-02-07T10:33:28Z

IGNITE-7514 Affinity assignment should be recalculated when primary node is 
not OWNER

(cherry picked from commit faf50f1)

commit d3745e9d0a3ff5a64fba494889b7e2605f3af6bb
Author: Alexey Goncharuk 
Date:   2018-02-07T18:10:32Z

IGNITE-7639 Fixed NPE

commit 421b2b9554cc0400be3ec95c07efffca409d07dd
Author: Stanislav Lukyanov 
Date:   2018-02-08T22:25:11Z

IGNITE-7464 - Add property to configure time between node connection 
attempts - Fixes #3493

commit f7c16855ba802d9d47048521aec7e14285e4a281
Author: Pavel Kovalenko 
Date:   2018-02-09T13:55:15Z

IGNITE-7540 Prevent page memory metadata corruption during checkpoint and 
group destroying. - Fixes #3490.

Signed-off-by: Alexey Goncharuk 

commit 2eec607b36186c05f92fae71b30d61d43eda4a69
Author: Nikolay Izhikov 
Date:   2018-02-09T04:00:54Z

IGNITE-7337: Implementation of saving DataFrame to Ignite SQL tables - 
Fixes #3438.

commit c92f167fc491078f02b9f94fe89edafc2902ebc2
Author: ilantukh 
Date:   2018-02-14T12:40:13Z

Updated version in properties.

commit 1ecf348dd429cf7861b414e0e5a7776b72dba281
Author: Sergey Chugunov 
Date:   2018-02-16T13:21:12Z

IGNITE-7699 BinaryMetadata exchange should not be triggered if metadata was 
not updated - Fixes #3523.

Signed-off-by: Alexey Goncharuk 

(cherry-picked from commit bcd3881)

commit 2458bd08a5b501b3eeb5caf0ae6dcaa2bcccd915
Author: EdShangGG 
Date:   2018-02-16T13:29:49Z

IGNITE-7676 Add affinity version to snapshot plugin stub - Fixes #3510.

Signed-off-by: Alexey Goncharuk 
(cherry picked from commit b6d21fb)

commit 

[jira] [Created] (IGNITE-8631) IgniteInstanceResource doesn't inject the Ignite instance to Ignite Predicate during deploying cache with nodeFilter

[Andrey Aleksandrov (JIRA)]

Andrey Aleksandrov created IGNITE-8631:
--

 Summary: IgniteInstanceResource doesn't inject the Ignite instance 
to Ignite Predicate during deploying cache with nodeFilter
 Key: IGNITE-8631
 URL: https://issues.apache.org/jira/browse/IGNITE-8631
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.4
Reporter: Andrey Aleksandrov
 Fix For: 2.6


Next code:
{code:java}
Ignite ignite = IgnitionEx.start("examples/config/example-ignite.xml", 
"ignite-1");
Ignite ignite2 = IgnitionEx.start("examples/config/example-ignite.xml", 
"ignite-2");


ignite2.createCache(new CacheConfiguration()
.setName("my-cache")
.setNodeFilter(new IgnitePredicate() {
@IgniteInstanceResource Ignite filterIgnite;

@Override public boolean apply(ClusterNode node) {
System.out.println("Is local node: " + node.isLocal());
System.out.println("ignite: " + (isNull(filterIgnite) ? null : 
filterIgnite.name()));
return true;
}
})
);

{code}
Produces next output:
{code:java}
Is local node: true
ignite: null
Is local node: true
ignite: null
Is local node: false
ignite: null
Is local node: false
ignite: null
Is local node: false
ignite: null
Is local node: false
ignite: null
Is local node: true
ignite: null
Is local node: true
ignite: null
Is local node: true
ignite: null
Is local node: true
ignite: null
Is local node: true
ignite: null
{code}
Looks like @IgniteInstanceResource doesn't work in this case.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #4080: IGNITE-8122 Backport to 2.4

[Jokser]

GitHub user Jokser opened a pull request:

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

IGNITE-8122 Backport to 2.4



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

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

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

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


commit 915dd2966084d78f7b4f3d482e6bd25f860c1e23
Author: Alexey Goncharuk 
Date:   2018-01-31T08:22:26Z

IGNITE-7569 Fixed index rebuild future - Fixes #3454.

commit 8ea8609259039852ab0c26f26ac528c1ffae7c94
Author: Alexey Goncharuk 
Date:   2018-01-31T08:24:57Z

IGNITE-7577 Fixing public API active flag on baseline changes - Fixes #3455.

commit d1a23c684dfadedf2b28966a223684827f3c5d7b
Author: David Wimsey 
Date:   2018-01-31T08:47:25Z

IGNITE-7576 Scripts: fix version check regexp to handle OpenJDK

This closes #3456

commit c8ce1f66e98b3174d771a3b801a2538499dc2c3d
Author: Ivan Rakov 
Date:   2018-01-31T09:51:09Z

IGNITE-7475 Improved VerifyBackupPartitionsTask to calculate partition 
hashes in parallel - Fixes #3407.

Signed-off-by: Alexey Goncharuk 

commit 258ff4299da20122d7c387cb8579264035c93c18
Author: Alexey Goncharuk 
Date:   2018-01-31T13:52:24Z

IGNITE-7573 Fixed full API tests to be compliant with baseline topology

commit aca3b8c664de8dcbbfeabbb0f8c252194d6ad1b2
Author: Pavel Tupitsyn 
Date:   2018-01-31T16:49:07Z

IGNITE-7473 .NET: Fix ConfigurationManager assembly error on Linux

commit 7bb61dfb1dcbcd759f159618a008bd02f6e6
Author: Alexey Kuznetsov 
Date:   2018-02-01T08:22:53Z

ignite-2.4.0 Update version.

(cherry picked from commit 2e43749)

commit 254ed3a9c32d092702a0461509bf867cbd7cdee6
Author: Alexey Kuznetsov 
Date:   2018-02-01T08:22:53Z

ignite-2.4.0 Update version.

(cherry picked from commit 2e43749)

commit d5782c53b8beab17ea4f953ad009d71b02fc335c
Author: artemmalykh 
Date:   2018-02-01T09:43:02Z

IGNITE-7590: fixed tree example

this closes #3459

(cherry picked from commit a9d40a7)

commit c1a9c0a404d77fba08170bedf14844f87abe3028
Author: Alexey Goncharuk 
Date:   2018-02-01T10:17:28Z

IGNITE-7569 Fixing index rebuild future

commit e43799ce70cdbe03d9e206381d1d5138b820b075
Author: Alexey Goncharuk 
Date:   2018-02-01T13:39:17Z

IGNITE-7520 Provide util-methods to get baseline from context - Fixes #3431.

commit a54bfd1a0906cee8394a0b495f61549ab63e4346
Author: dpavlov 
Date:   2018-02-01T15:31:12Z

IGNITE-7599 Missed licenses in ignite-direct-io module

Signed-off-by: Anton Vinogradov 

(cherry picked from commit d88af9b)
Signed-off-by: Anton Vinogradov 

commit 8f5fc7cfb0624cf2048efad38dfff32f782116e8
Author: Sergey Chugunov 
Date:   2018-02-02T08:24:29Z

IGNITE-7580 Fix compatibilityMode flag consistency

This closes #3466

(cherry picked from commit 8f2045e)

commit d3ddd50cb2b889173176b6c47c9ff61410e1d909
Author: Ilya Lantukh 
Date:   2018-02-07T10:33:28Z

IGNITE-7514 Affinity assignment should be recalculated when primary node is 
not OWNER

(cherry picked from commit faf50f1)

commit d3745e9d0a3ff5a64fba494889b7e2605f3af6bb
Author: Alexey Goncharuk 
Date:   2018-02-07T18:10:32Z

IGNITE-7639 Fixed NPE

commit 421b2b9554cc0400be3ec95c07efffca409d07dd
Author: Stanislav Lukyanov 
Date:   2018-02-08T22:25:11Z

IGNITE-7464 - Add property to configure time between node connection 
attempts - Fixes #3493

commit f7c16855ba802d9d47048521aec7e14285e4a281
Author: Pavel Kovalenko 
Date:   2018-02-09T13:55:15Z

IGNITE-7540 Prevent page memory metadata corruption during checkpoint and 
group destroying. - Fixes #3490.

Signed-off-by: Alexey Goncharuk 

commit 2eec607b36186c05f92fae71b30d61d43eda4a69
Author: Nikolay Izhikov 
Date:   2018-02-09T04:00:54Z

IGNITE-7337: Implementation of saving DataFrame to Ignite SQL tables - 
Fixes #3438.

commit c92f167fc491078f02b9f94fe89edafc2902ebc2
Author: ilantukh 
Date:   2018-02-14T12:40:13Z

Updated version in properties.

commit 1ecf348dd429cf7861b414e0e5a7776b72dba281
Author: Sergey Chugunov 
Date:   2018-02-16T13:21:12Z

IGNITE-7699 BinaryMetadata exchange should not be triggered if metadata was 
not updated - Fixes #3523.

Signed-off-by: Alexey Goncharuk 

[GitHub] ignite pull request #4079: IGNITE-8311: IgniteClientRejoinTest.testClientsRe...

[x-kreator]

GitHub user x-kreator opened a pull request:

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

IGNITE-8311: IgniteClientRejoinTest.testClientsReconnectDisabled caus…

…es exchange-worker to terminate via NPE.

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

$ git pull https://github.com/x-kreator/ignite ignite-8311

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

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


commit c4526c3b22b7d2c633af17ca79732c6e8722e2d5
Author: Dmitriy Sorokin 
Date:   2018-05-28T14:22:02Z

IGNITE-8311: IgniteClientRejoinTest.testClientsReconnectDisabled causes 
exchange-worker to terminate via NPE.




---

Re: I am sorry for causing confusion. IGNITE-6531

[Ilya Lantukh]

Welcome to Apache Ignite community!

The problem with your ticket is that it's not clear what value it adds to
the project and how it will improve user experience in general. The problem
you described is rather narrow and I am sure it's possible to find a
workaround without modifying Ignite code.
If you think that such option can be helpful in more general cases, please
explain why and how.

Thanks!

On Mon, May 28, 2018 at 4:27 PM, JD Nam  wrote:

> Hello Igniter!
>
> First of all, I'm sorry. I was not aware of the ignite community process
> well, so I did not follow the guideline and caused the confusion to the
> community.
> My name is joungdal.nam and I made the issue as following link.
> https://issues.apache.org/jira/browse/IGNITE-6531
>
> Pleases allow me to introduce myself.
> I am a java developer working in e-Commerce in a small country in Asia.
> Currently, I am developing a Spring based framework (for our company domain
> only).
>
> We had a little problems in developing our program, especially Batch.
> Most java developers in the company for which I work are domain experts,
> they are not getting away from jar-hell
> There are a lot of problems associated with CPU and memory, etc., because
> many java batches that are starting and shutdown by the scheduler work like
> many beans of spring.
> It is not possible to separate a module (lib) because it takes too much
> time and resources.
>
> When I saw ignite I shouted Eureka.
> By applying Spring-boot & Ignite's ComputeTask, I thought I'd have to a
> Distribute Batch Platform with Daemon.
> The main concept of this platform is to assign a job to a node with the
> lowest load through the matrix information of the ignite cluster.
> Since all CRUD work is handled by Oracle, ignite's distributed computing
> seemed to be of great help (source can not be hdfs.)
> I do not want to shutdown manually, so, the client node is managed by
> initiating shutdown if the count of running nodes reaches the threshold
> value by using userAttribute. The version is named to jar file name and
> build time as postfix.
>
> Sorry. I'll get to the point. The reason why I created IGNITE-6531 is that
> the batch of my company has too many beans.
> Unfortunately, I am not able to tell which lib contains a particular bean.
> Moreover, I am not able to remove the lib even if I find the lib (the
> product may not be delivered to the customer)
> Certain beans only work in stg, prod in dev, qa, stg, prod (external
> communication issue or firewall problem)
> Due to the nature of our Traditional Business, instances of beans are
> created only under certain circumstances and cannot be injected in other
> environments.
>
> After all, the best way to do this is to treat it the same as the method of
> the spring framework.
> When injecting another spring bean in ComputeTask,  we could write it just
> like @AutoWired (required = false).
> I did not want to see the non-operation of the daemon because of a runtime
> exception due to a firewall problem.
> So, I thought “required = false” is required @SpringResource.
> Hope to hear your opinion on this.
> Once, again, I would like to apologize that I did not aware of the ignite
> process.
>
>
>
> I also have another question. I heard that there is an issue with
> configuration on the mailing list.
> How deploy node with different env, do you use it as below?
>
> In the java code,
> try (Ignite ignite = Ignition.start("/config/ignite.xml")) { // deault
> zone
> try (Ignite ignite = Ignition.start("/config/ignite-dev.xml")) { // dev?
> try (Ignite ignite = Ignition.start("/config/ignite-qa.xml")) { // qa?
> try (Ignite ignite = Ignition.start("/config/ignite-stg.xml")) { // stg??
>
> It will be a more user friendly settling by using yaml. Our project has
> over 300 properties
> If yaml is supported by ignite, it would be much more convenience. (If you
> do not have a plan to support spring-boot)
> I used ignite-default.yml, ignite-dev.yml, etc in my project. By
> distinguishing java -D options, codes are not revised and I only read
> configuration.
>
>
>
> I think there's a mistype in the document of the link below.
> It is the example of SqlFieldsQuery.
> https://apacheignite-sql.readme.io/docs/java-sql-api
> try (QueryCursor > cursor = cache.query (sql) {
>
> I think there should be one more ')' as below.
> = cache.query (sql))  {
>
> I'll try to read the contribute documentation to fix this issue.
> It's better if you fix it.
> Ignite is really cool, you guys are really great.
>



-- 
Best regards,
Ilya

[GitHub] ignite pull request #4078: IGNITE-8482 2-phase partition release wait optimi...

[Jokser]

GitHub user Jokser opened a pull request:

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

IGNITE-8482 2-phase partition release wait optimization



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

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

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

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


commit b9bef2d655bd8fea9ab4976577532029979b462f
Author: Pavel Kovalenko 
Date:   2018-05-28T13:36:19Z

IGNITE-8482 Do not perform distributed partition release wait in case of 
cluster activation or caches start.

commit 66dd1c5795f80aa8a8f775633f8f1b2ab9c5b2fd
Author: Pavel Kovalenko 
Date:   2018-05-28T13:38:51Z

IGNITE-8482 Skip partitions validation in case of caches start.




---

I am sorry for causing confusion. IGNITE-6531

[JD Nam]

Hello Igniter!

First of all, I'm sorry. I was not aware of the ignite community process
well, so I did not follow the guideline and caused the confusion to the
community.
My name is joungdal.nam and I made the issue as following link.
https://issues.apache.org/jira/browse/IGNITE-6531

Pleases allow me to introduce myself.
I am a java developer working in e-Commerce in a small country in Asia.
Currently, I am developing a Spring based framework (for our company domain
only).

We had a little problems in developing our program, especially Batch.
Most java developers in the company for which I work are domain experts,
they are not getting away from jar-hell
There are a lot of problems associated with CPU and memory, etc., because
many java batches that are starting and shutdown by the scheduler work like
many beans of spring.
It is not possible to separate a module (lib) because it takes too much
time and resources.

When I saw ignite I shouted Eureka.
By applying Spring-boot & Ignite's ComputeTask, I thought I'd have to a
Distribute Batch Platform with Daemon.
The main concept of this platform is to assign a job to a node with the
lowest load through the matrix information of the ignite cluster.
Since all CRUD work is handled by Oracle, ignite's distributed computing
seemed to be of great help (source can not be hdfs.)
I do not want to shutdown manually, so, the client node is managed by
initiating shutdown if the count of running nodes reaches the threshold
value by using userAttribute. The version is named to jar file name and
build time as postfix.

Sorry. I'll get to the point. The reason why I created IGNITE-6531 is that
the batch of my company has too many beans.
Unfortunately, I am not able to tell which lib contains a particular bean.
Moreover, I am not able to remove the lib even if I find the lib (the
product may not be delivered to the customer)
Certain beans only work in stg, prod in dev, qa, stg, prod (external
communication issue or firewall problem)
Due to the nature of our Traditional Business, instances of beans are
created only under certain circumstances and cannot be injected in other
environments.

After all, the best way to do this is to treat it the same as the method of
the spring framework.
When injecting another spring bean in ComputeTask,  we could write it just
like @AutoWired (required = false).
I did not want to see the non-operation of the daemon because of a runtime
exception due to a firewall problem.
So, I thought “required = false” is required @SpringResource.
Hope to hear your opinion on this.
Once, again, I would like to apologize that I did not aware of the ignite
process.



I also have another question. I heard that there is an issue with
configuration on the mailing list.
How deploy node with different env, do you use it as below?

In the java code,
try (Ignite ignite = Ignition.start("/config/ignite.xml")) { // deault zone
try (Ignite ignite = Ignition.start("/config/ignite-dev.xml")) { // dev?
try (Ignite ignite = Ignition.start("/config/ignite-qa.xml")) { // qa?
try (Ignite ignite = Ignition.start("/config/ignite-stg.xml")) { // stg??

It will be a more user friendly settling by using yaml. Our project has
over 300 properties
If yaml is supported by ignite, it would be much more convenience. (If you
do not have a plan to support spring-boot)
I used ignite-default.yml, ignite-dev.yml, etc in my project. By
distinguishing java -D options, codes are not revised and I only read
configuration.



I think there's a mistype in the document of the link below.
It is the example of SqlFieldsQuery.
https://apacheignite-sql.readme.io/docs/java-sql-api
try (QueryCursor > cursor = cache.query (sql) {

I think there should be one more ')' as below.
= cache.query (sql))  {

I'll try to read the contribute documentation to fix this issue.
It's better if you fix it.
Ignite is really cool, you guys are really great.

[GitHub] ignite pull request #4077: IGNITE-8624: Add reproducer to IGNITE-8624 issue.

[ivandasch]

GitHub user ivandasch opened a pull request:

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

IGNITE-8624: Add reproducer to IGNITE-8624 issue.



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

$ git pull https://github.com/ivandasch/ignite ignite-8624

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

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


commit 372d3026218fcb36b6b84751cf6384e7d5cd513b
Author: Ivan Daschinskiy 
Date:   2018-05-28T12:47:05Z

IGNITE-8624: Add reproducer to IGNITE-8624 issue. After fix it passes.




---

[jira] [Created] (IGNITE-8627) Verify local partition map against global

[Stanislav Lukyanov (JIRA)]

Stanislav Lukyanov created IGNITE-8627:
--

 Summary: Verify local partition map against global
 Key: IGNITE-8627
 URL: https://issues.apache.org/jira/browse/IGNITE-8627
 Project: Ignite
  Issue Type: Improvement
Reporter: Stanislav Lukyanov
Assignee: Alexey Goncharuk


IGNITE-7467 introduced verification of partition update counters and sizes 
between replicas.

Similarly, it's possible to verify that local copy of the partition map doesn't 
differ from the map on the other nodes, detecting issues that may lead to 
inconsistent reads or data loss.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8626) ODBC: Can not compile ODBC with OpenSSL 1.1

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-8626:
---

 Summary: ODBC: Can not compile ODBC with OpenSSL 1.1
 Key: IGNITE-8626
 URL: https://issues.apache.org/jira/browse/IGNITE-8626
 Project: Ignite
  Issue Type: Bug
  Components: odbc
Affects Versions: 2.4
Reporter: Igor Sapego
 Fix For: 2.6


Can not compile ODBC with OpenSSL 1.1.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8625) Dynamic SQL index recreate after cache clear may result in AssertionError or JVM crash

[Ivan Rakov (JIRA)]

Ivan Rakov created IGNITE-8625:
--

 Summary: Dynamic SQL index recreate after cache clear may result 
in AssertionError or JVM crash
 Key: IGNITE-8625
 URL: https://issues.apache.org/jira/browse/IGNITE-8625
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Rakov
 Fix For: 2.6


After recreation of previously dropped SQL index, root page of new index B+ 
tree may contain links to data entries from previous index tree. If they were 
removed or relocated to another data page, attempt to dereference these links 
may throw AssertionError or even cause JVM crash.
Patch with reproducer is attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8624) Add test coverage for NPE in TTL Manager [IGNITE-7972]

[Ivan Daschinskiy (JIRA)]

Ivan Daschinskiy created IGNITE-8624:


 Summary: Add test coverage for NPE in TTL Manager [IGNITE-7972]
 Key: IGNITE-8624
 URL: https://issues.apache.org/jira/browse/IGNITE-8624
 Project: Ignite
  Issue Type: Test
Reporter: Ivan Daschinskiy
Assignee: Ivan Daschinskiy


Add test coverage (reproducer) to the [IGNITE-7972] case.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8623) NPE during cache access

[Alexey Stelmak (JIRA)]

Alexey Stelmak created IGNITE-8623:
--

 Summary: NPE during cache access
 Key: IGNITE-8623
 URL: https://issues.apache.org/jira/browse/IGNITE-8623
 Project: Ignite
  Issue Type: Bug
Reporter: Alexey Stelmak






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8622) Zookeeper and TCP discovery SPI' getSpiState method inconsistent

[Max Shonichev (JIRA)]

Max Shonichev created IGNITE-8622:
-

 Summary: Zookeeper and TCP discovery SPI' getSpiState method 
inconsistent
 Key: IGNITE-8622
 URL: https://issues.apache.org/jira/browse/IGNITE-8622
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.5
Reporter: Max Shonichev
 Fix For: 2.6


getSpiState of TcpDiscoverySpi Mbean returns uppercased human-readable state, 
e.g. 'CONNECTED'

getSpiState of ZookeeperDiscoverySpi Mbean returns camelcased one, e.g. 
'Connected'



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #4062: IGNITE-8567: Imputer and Binarizer

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Created] (IGNITE-8621) TcpDiscoverySpi's UpTime/StartTimestamp methods do not work

[Max Shonichev (JIRA)]

Max Shonichev created IGNITE-8621:
-

 Summary: TcpDiscoverySpi's UpTime/StartTimestamp methods do not 
work
 Key: IGNITE-8621
 URL: https://issues.apache.org/jira/browse/IGNITE-8621
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.5
Reporter: Max Shonichev
 Fix For: 2.6
 Attachments: Screenshot from 2018-05-28 12-57-13.png

getUpTime and getStartTimestamp methods of TcpDiscoverySpiMBeanImpl returns 0, 
which does not look like normal value

also, getUpTimeFormatted returns 00:00:00.000 and getStartTimestampFormatted 
returns Jan 1, 1970





--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8620) Remove intOrder and lc keys from node info in control.sh --tx utility

[Dmitry Sherstobitov (JIRA)]

Dmitry Sherstobitov created IGNITE-8620:
---

 Summary: Remove intOrder and lc keys from node info in control.sh 
--tx utility
 Key: IGNITE-8620
 URL: https://issues.apache.org/jira/browse/IGNITE-8620
 Project: Ignite
  Issue Type: Improvement
Reporter: Dmitry Sherstobitov


For now this information displayed in control.sh utility for each node:

TcpDiscoveryNode [id=2ed402d5-b5a7-4ade-a77a-12c2feea95ec, 
addrs=[0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.25.1.47], 
sockAddrs=[/0:0:0:0:0:0:0:1%lo:0, /127.0.0.1:0, /172.25.1.47:0], discPort=0, 
order=6, intOrder=6, lastExchangeTime=1526482701193, loc=false, 
ver=2.5.1#20180510-sha1:ee417b82, isClient=true]

loc and intOrder values are internal information and there is not need to 
display it

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8619) 'Remote node could not start' in ssh connection

[Ivan Fedotov (JIRA)]

Ivan Fedotov created IGNITE-8619:


 Summary: 'Remote node could not start' in ssh connection
 Key: IGNITE-8619
 URL: https://issues.apache.org/jira/browse/IGNITE-8619
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Fedotov


Now there is a problem with launch remote node via ssh. Initially was an 
assumption that it's due to remote process has not enough time to write 
information into log: 
[IGNITE-8085|https://issues.apache.org/jira/browse/IGNITE-8085]. But this 
correction didn't fix [TeamCity 
|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6814497542781613621=testDetails].
 
So now it's necessary to make launch remote node via ssh always succesful.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8618) Support Java 10

[Anghel Botos (JIRA)]

Anghel Botos created IGNITE-8618:


 Summary: Support Java 10
 Key: IGNITE-8618
 URL: https://issues.apache.org/jira/browse/IGNITE-8618
 Project: Ignite
  Issue Type: Task
Affects Versions: 2.4
Reporter: Anghel Botos


Please make required changes so that Ignite runs on Java 10.

The blocking issue I encontered is related to the usage of Unsafe:

Caused by: java.lang.RuntimeException: jdk.internal.misc.JavaNioAccess class is 
unavailable.
 at 
org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1459)
 at org.apache.ignite.internal.util.GridUnsafe.(GridUnsafe.java:118)
 ... 30 more
Caused by: java.lang.IllegalAccessException: class 
org.apache.ignite.internal.util.GridUnsafe cannot access class 
jdk.internal.misc.SharedSecrets (in module java.base) because module java.base 
does not export jdk.internal.misc to unnamed module @754ba872
 at 
java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:360)
 at 
java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:589)
 at java.base/java.lang.reflect.Method.invoke(Method.java:556)
 at 
org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1456)
 ... 31 more

 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #4076: IGNITE-8617 Node Discovery Using AWS Application ...

[udaykale]

GitHub user udaykale opened a pull request:

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

IGNITE-8617 Node Discovery Using AWS Application ELB



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

$ git pull https://github.com/udaykale/ignite IGNITE-8617

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

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


commit 08147dd1eb666b7cd334d327d20795c40f2a3a75
Author: uday 
Date:   2018-05-28T05:52:07Z

IGNITE-8617 Node Discovery Using AWS Application ELB




---